Очень короткий и забавный скринкаст о том, чего делать не стоит, даже чрезмерно увлекаясь виртуализацией. Например, виртуализировать все контроллеры домена и Virtual Machine Manager.
Очень короткий и забавный скринкаст о том, чего делать не стоит, даже чрезмерно увлекаясь виртуализацией. Например, виртуализировать все контроллеры домена и Virtual Machine Manager.
13 комментариев:
Пятничный пост? -)
К слову, развертывание SCVMM на виртуальной машине явление из области best practices. Но, как показывает практика, у нас (да и не у нас, судя по касту) к процессу виртуализации подходят с излишним фанатизмом -)
Обновка!?
Ну про DC не соглашусь, почему бы их и не виртуализировать ВСЕ.
Могу предположить что история повторится,
как было несколько лет назад MS заявляла что виртуализация это не для продуктива, в тоже время VMware говорила о виртуализации продутива кроме vCenter-a (аналог MS VMM)!
Уже сегодня установка vCenter как Gest VM поддерживается! более того иногда это единственное и правильное решение! В тоже время MS с Hyper-V уже говорит о виртуализации продуктива, но для SCVMM мы видим подобные рассказы что не надо все виртуализировать, пройдет время и MS скажет что “нов итс фули супортетд фолкс!” и SCVMM уже будут поддерживать и рекомендовать ставить в виртуальной среде.
К примеру у нас в орг на 95% все виртулизировано!
Arman.
Денис, не пятничный. Действительно очень интересно и отчетливо показано, что виртуализацию нужно тщательно планировать, как и все остальное, впрочем. Жаль, что сам не додумался до такого способа =)
Арман: "обновка" это про внешний вид блога? Тогда да - вчера оттестил новый блогспотовский дизайнер тем. Надо доработать, а то баннеры снизу уползают...
Что касается "как всегда"... Видите ли, тут суть не в том, что что-то нельзя виртуализировать. Можно все (есть пока некоторые нагрузки, которые в виртуальной среде не поддерживаются, например какая-то из ролей OCS), только делать это нужно с головой. Примеры:
1) сиквел, которому нужно отдать, скажем, 128Г памяти виртуализировать особого смысла нет.
2) Если ему нужно "всего" 64Г, то виртуализировать смысл может появиться, но нужно будет настраивать кучу проверок, которые не особо нужны в случае более мелких нагрузок.
3) Виртуализировать все DC на одной ферме, серверы в которой входят в тот же домен - верный путь в никуда. И не надо мне говорить, что, мол, какой идиот так сделает - я таких уже видел =)
4) Виртуализировать SC VMM на той же ферме, которой он управляет можно только если этот самый VMM не особо-то и нужен, но зачем тогда его покупать? =)
Ну и так далее. Просто тема долгое время была "модной", и когда ей пришло время становиться просто инструментом, народ по привычке считает, что нашел "серебрянную пулю".
Глупость полная. Из ружья можно выстрелить себе в ногу, а физические контроллеры доменов можно тупо сжечь или порубать топором.
Проблемы начинаются, если нет бэкапов. Но если есть большая виртуальная инфраструктура и нет бэкапов, то это уже к психиатру.
А... Видел таких храбрых партизан. Однако, вот у меня такие требования, чтобы бекапы были нужны только для того, чтобы их проверять. Если я буду по каждому чиху восстанавливать все из руин - стоимость такой поддержки будет неимоверно выше, стоимости грамотно спланированной инфраструктуры. Хотя бы потому, что проблемы у меня заканчиваются в большинстве случаев раньше, чем начинается необходимость восстановить из бекапа что бы то ни было. =)
Проблема в том, что если уповать только на бекап, не продумывая архитектуру решения в целом, то при падении одного двух серверов можно получить полностью нерабочую инфраструктуру, а потом до посинения восстанавливать ее, когда можно просто сделать пару движений в консольке того же VMM и пойти дальше досыпать. И заметьте, нигде не было произнесено, что при грамотно настроенной инфраструктуре бекапы не нужны. Хотя, надо признаться, сфера их принменения несколько смещается.
В свое время в блоге собирал "солянку", что можно виртуализовать из сервисов MS на платформе MS же, что нет - http://ddyagilev.ru/?p=75
Вопрос в том, что подходить надо к этому с умом, дабы не всплыли впоследствии ошибки в просчетах.
В свое вреимя напоролись на тот момент при довольно неплохом планировании при переводе в виртуальную среду инфраструктуры, что "тяжелый" физический SQL заводился позднее виртуализованного ISA - как результат проблемы с логированием. Выяснилось чисто случайно -)))
Просто оставлю здесь две цитаты: одна Ваша и одна моя. Моя написана второй, хотя была опукбликована первой. Будем спорить дальше, кто из нас более друг с дружкой согласен? =)
>>Вопрос в том, что подходить надо к этому с умом, дабы не всплыли впоследствии ошибки в просчетах
>>виртуализацию нужно тщательно планировать
Какбэ и не собираюсь спорить в этом ключе -)
Просто "все спланировать" не получится. Тем более в ключе виртуализации, которая, как выше отметил Арман, относительно нова.
Все - не получится. Но ээто не значит, что нужно игнорировать элементарые вещи типа:
1) не храни систему управления яйцами в той же корзине, что и сами яйца.
2) Не делай бекапы сиквела на диск, на котором лежат его базы.
3) Если ты сделал CCR для Exchange на виртуалке - поставь его ноды на разные фермы
ну и так далее. Повторюсь: это все (кроме п.1 - не знаю, что бы из себя представляла система управления яйцами =) ) примеры из real life.
…ага я про фейс, симпотный, только темноват немного, обычно я утро начинаю с просмотра блогов, подумал сначала что не туда попал
согласен с вами что "тупо" делать некоторые вещи, но как говорится все беды от нашего (или их) незнания.
Про яйцеделку конечно так и есть да и про бэкапы, хотя по бэкапам можно порассуждать, смотря какую цель преследует этот самый бэкап который делается там же, может для восстановления базы от случайных удалённых таблиц, а не для полного восстановления, а полное восстановление делается из имиджа виртуальной машины :)
Ну в итоге я могу сказать от себя это все зависит от конкретного сценария, и только.
Arman
Арман, ну мы же беседуем о продуктиве, а не о тестовой среде, правда? Ну какие "бекапы на локальный диск для восстановления таблиц"? Тут сразу несколько фаторов вступает: и само по себе - никакой гарантии, что хоть что-то восстановишь, и I/O дорогое, и место тоже недешевое, ибо быстрое и отказоустойчивое. А бекапить сиквел путем имиджевания начиная с некотороых рамеров баз тоже очень неудобно - встроенный лучше =)
Но если речь идет о базе на "потестировать" или MSDE, на котором крутится "CRM" в виде одной таблицы, тогда да, тогда можно и на локальный диск, и бекапить, как придется, хоть в Excel скриптом ежедневно сливать =)
В общем, все это было задумано не для того, чтобы померяться, "кто круче всех системы строить умеет", а для того, чтобы напомнить (самому себе, в том числе), что нет серебрянных пуль и любая супер-пупер технология имеет свою Темную сторону =)
вот вот
все зависит от конкретного сценария, и только!
тот-же CRM с одной таблицей ;)
Ну как скажете =)
Отправить комментарий