tag:blogger.com,1999:blog-5320167098569797652.post1647889600371975744..comments2023-06-08T14:48:40.610+03:00Comments on Записки виртуального админа: Про vSwitch'и. Разъяснение.Anton Zhbankovhttp://www.blogger.com/profile/00989828695484228304noreply@blogger.comBlogger6125tag:blogger.com,1999:blog-5320167098569797652.post-51901491280175178332009-01-28T19:38:00.000+03:002009-01-28T19:38:00.000+03:00По первому пункту согласен на 100%. Я поэтому и на...По первому пункту согласен на 100%. Я поэтому и написал в своём предыдущем комментарии, что всего предусмотреть невозможно и всегда будет что-то новое. А вот пункт второй вызывает серьёзные возражения в двух местах:<BR/>1. Про документацию. Не вижу ни какой проблемы в ведении оной. Как правило vSwitch добавляется во всех ESX'ах, входящих в один HA Cluster. Не могу представить себе ситуацию, кроме как совершенно фантастических, когда на таком [8-и портовом] свитче будет определено более одной порт-группы. Соответственно, в доках пишется, что-то подобное: "Внимание! Суммарное количество сетевых интерфейсов подключённых к порт-группе Х не должно превышать восьми!" И совершенно не важно количество ESX'ов, будь их там хоть 32.<BR/>2. Про переполнение стандартного vSwitch'а. Возможность конечно существует, но называть реальной её, я бы не стал. На среднем ESX'е бежит от 10 до 20 VM'ок. В стандартном сервере очень редко используются более 2-х сетевых карточек [у нас в ЦОДе порядка 1000 серверов, из них больше двух сетевух имеют только те, что стоят в MS кластерах да firewall'ы]. Простая арифметика говорит нам, что до 56-и у нас есть ещё солидный запас. Конечно, бывают фирмы, занимающиеся узкоспециализированными сетевыми задачами, где в серваках напихано куча всего, или организации, где штампуют VM'ы, как булочки, а они в конечном итоге простаивают без работы и, как следствие, на ESX'ах там бежит по 25-30-40 виртуалок. Но сколько таких фирм/организаций?<BR/><BR/>А вообще, будем ждать выхода vSphere: там и vNetwork Distributed Switch появится, что облегчит мониторинг, и ConfigControl встроенный. И, будем надеяться, что и БОЛЬШИЕ КРАСНЫЕ БУКВЫ нас оповещать будут :-)Vasillihttps://www.blogger.com/profile/01613867830042540436noreply@blogger.comtag:blogger.com,1999:blog-5320167098569797652.post-75191486800583613132009-01-28T18:52:00.000+03:002009-01-28T18:52:00.000+03:00Поведение правильное. Это я как тестер бывший гово...Поведение правильное. Это я как тестер бывший говорю)Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5320167098569797652.post-89544362777698935382009-01-28T18:11:00.000+03:002009-01-28T18:11:00.000+03:001) Чтобы настроить реакцию syslog на данное сообще...1) Чтобы настроить реакцию syslog на данное сообщение, нужно для начала знать что это за сообщение, в каких случаях появляется и что оно вообще существует.<BR/>2) Стандартный vSwitch из VI клиента содается с 56 (64) портами. Реальная возможность в определенных условиях получить переполнение vSwitch'а и недоступность сервисов. Разумеется, не такая, как с 8 (16), но тем не менее.<BR/>С задокументированностью можно сразу распрощаться. Машины на vSwitch добавляются не напрямую, а автоматом, согласно порт-групп. И более того, они еще и бегают по разным ESX.Anton Zhbankovhttps://www.blogger.com/profile/00989828695484228304noreply@blogger.comtag:blogger.com,1999:blog-5320167098569797652.post-80756309597174155012009-01-28T17:05:00.000+03:002009-01-28T17:05:00.000+03:00Всё правильно и БОЛЬШИЕ КРАСНЫЕ БУКВЫ - ЭТО MUST, ...Всё правильно и БОЛЬШИЕ КРАСНЫЕ БУКВЫ - ЭТО MUST, но...<BR/>1. Насчёт Syslog'а: он не только должен быть неким сборищем информации, но и передавать, в случае необходимости, эту информацию дальше. Если, как Антон говорит, ESX'ов пара десятков, то организация должна быть достаточно серьёзной и иметь централизованную систему мониторинга. Мы, например, используем CA Unicenter. Вот там-то и должны, в конечном итоге, появлятся БОЛЬШИЕ КРАСНЫЕ БУКВЫ и загораться разноцветные лампочки. Понятно, что всего предусмотреть невозможно и всегда будет что-то новое.<BR/>2. Если ESX админ, по каким-то причинам решил определить восьми портовый vSwitch, то для этого должна быть какая-то веская причина [скорее всего что-то связанное с security]. Соответственно должна быть определённая <B><I>задокументированная</I></B> процедура по добавлению серверов в этот свитч. Конечно, все мы не без греха, и человеческий фактор никто не отменял, но мне кажется, что появление проблем в данной ситуации можно избежать.Vasillihttps://www.blogger.com/profile/01613867830042540436noreply@blogger.comtag:blogger.com,1999:blog-5320167098569797652.post-39658840254656664362009-01-28T15:17:00.000+03:002009-01-28T15:17:00.000+03:00Правильно настроенный syslog сервер должен быть, б...Правильно настроенный syslog сервер должен быть, без всяких вопросов.<BR/><BR/>Но все же копаться в мегабайтах логов не самое простое и очевидное занятие. Когда ESX'ов один-два и машин десяток - да, можно и там.<BR/><BR/>А если пара десятков одних ESX'ов, например? И машин несколько сотен. И в логах какого именно ESX'а автоматического DRS кластера копаться нужно?<BR/><BR/>Претензия в том, что вырубается сеть на машинах тихо, без предупреждений БОЛЬШИМИ КРАСНЫМИ БУКВАМИ. А причин почему нет сети может быть любое количество.Anton Zhbankovhttps://www.blogger.com/profile/00989828695484228304noreply@blogger.comtag:blogger.com,1999:blog-5320167098569797652.post-38633575076528189862009-01-28T13:14:00.000+03:002009-01-28T13:14:00.000+03:00Выводы? Правильно настроенный Syslog сервер и регу...Выводы? <BR/>Правильно настроенный Syslog сервер и регулярное его обследованние на предмет вот таких неприятностей. У кого другие соображения?Vasillihttps://www.blogger.com/profile/01613867830042540436noreply@blogger.com