вторник, 10 мая 2011 г.

esx2esxi?

Сегодня, в четвертой версии vSphere, присутствуют две версии гипервизора VMware - ESX и ESXi. Ваша компания использует какой-то один из них.

Завтра, в пятой версии, останется только ESXi.

VMware рекомендует использовать ESXi уже сейчас не только тем, кто только начинает разворачивать vSphere, но и уже живущим с ESX - т.е. мигрировать с ESX на ESXi

Хотя у VMware есть документы, книги, онлайн и оффлайн курсы по этому делу - миграция, обычно, штука не сложная. См. картинку:

Ситуация сложнее в случае если используются продукты, интегрирующиеся в всферу. Этими продуктами могут быть как продукты, поддерживающие оба гипервизора, так и только ESX.

В первом случае, например при использовании vShield или Nexus1000v, просто чуть больше работы при миграции.

А во втором, обычно это агенты мониторинга/управления железа сервера, миграция будет неоправдана - до сих пор ESXi не обзавелся возможностью на любом железе мониторить статус рейд-массива или ошибки памяти, а неспециальноподнегосделанный софт завести вряд ли удасться.

И я даже еще немного вброшу - даже если ничего интегрирующегося у вас не используется, и сейчас вы используете ESX - лично я не вижу веских причин затевать миграцию.

Нет, правда, зачем? Вернее, причины-то можно найти, я вижу основными узкоспециализированность ESXi и (возможно!) более простую миграцию на vSphere 5.

А вот оправданно ли затевать миграцию нормально работающей инфраструктуры ради не совсем конкре ной выгоды - я не уверен. Первую заповедь админа никто не отменял ;-).




10 комментариев:

  1. Этот комментарий был удален автором.

    ОтветитьУдалить
  2. Я вижу одну причину. Причём она заведомо не технического характера, а скорее философского (ну, ты же первый начал про «заповедь админа»).

    Вероятно, при миграции на «i» возникнут проблемы. Собственно, ты же сам об этом и пишешь. Лучше столкнуться с ними сейчас — и поискать решения, пока у вас ещё есть на это время.

    (Даже если вы сейчас думаете, что у вас времени нет — почему вдруг завтра его станет больше? Обычно почему-то как раз бывает строго наоборот).

    Завтра вы начнёте миграцию на vSphere 5 — и лучше минимизировать количество факторов, изменяемых за раз. Ибо если (когда) возникнут проблемы — будет сложнее понять, что именно является источником.


    Ну и чтобы камент был не полностью флеймовым — если кто ещё не в курсе, то см. формочку вот тут: http://communities.vmware.com/community/vmtn/desktop/workstation

    ОтветитьУдалить
  3. Артем, я с аргументом и соглашусь и нет - и не соглашусь вот с чем:

    Пока что у меня нет подтверждения что при миграции esxi4 -> esxi5 подводных камней не будет.

    Или, с другой стороны, что они будут хоть немного отличаться в ситуациях esxi4 -> esxi5 vs. esx4 -> esxi4.

    И вот в силу этой неопределенности я и делаю вывод о том, что смысла мигрировать сейчас не вижу.

    ОтветитьУдалить
  4. Анонимныйсреда, 11 мая, 2011

    //...вклиниваясь между Артёмом и Михаилом...//

    Господа, ИМХуется мне, что до <> времени разобраться с "подводными граблями" хватит... ;)
    Это я так скромно намекаю, что раньше переползать на "пятёру" не надо бы... :)

    С уважением,
    Umlyaut.

    ОтветитьУдалить
  5. Анонимныйсреда, 11 мая, 2011

    ... блин, закавычил в предыдущем комменте двойными "галками" - а оно возьми и сожрись. Там где < > - там было "v.5 U1" - "пятёра апдейт первый"... в смысле - до неё можно не торопясь (переходить) разбираться с миграцией...

    С уважением,
    Umlyaut.

    ОтветитьУдалить
  6. Миш, так я про то и говорю, что у нас будет два набора «граблей» и подводных камней.

    1. Переход с ветви «не-i» на «i».
    2. Переход с 4.х на 5.х.

    Ты предлагаешь объединить эти процессы, и таким образом разом словить обе порции граблей. В результате будет сложнее локализовать и найти первопричину каждой отдельной проблемы.

    Мне в подобных ситуациях представляется целесообразным разбивать этот процесс на два этапа. Между которыми можно получить чётко фиксируемый и проверяемый стабильный результат. (На который потом будет проще вернуться, если второй этап пойдёт не так гладко, как ожидалось).

    ОтветитьУдалить
  7. да, и вот ещё что. Я же правильно понимаю, что это такой специальный пост для вбросов, да?

    Так вот — я, как представитель компании, зарабатывающей на продаже ПО, не могу не отметить следующее. Откладывают обновления до выхода версии «x.1», «Update 1» или «SP1» только законченные неудачники и трусы :)

    ОтветитьУдалить
  8. про разумность разбиения на два этапа я не очень согласен (времени не дофига :)), но твою точку зрения я понял.

    про x.1 жжошь ;-)

    ОтветитьУдалить
  9. Анонимныйсреда, 11 мая, 2011

    Да Вы, Артём, записной провокатор, как мне глянется... :)))

    Впрочем, "представителю компании, зарабатывающей на продаже ПО" сам бог велел пуститься во все тяжкие в попытках увеличить аудиторию подопытных кро... пардон, бесплатных (для компании) тестеров - кто ж будет тратиться на ловлю багов самоновейшей версии своими силами, когда можно взять на слабО кучную кучу народа... :D

    С уважением,
    Umlyaut.

    ЗЫ: если что, я и ОС до первого SP в продакшн совать остерегаюсь... :P

    ОтветитьУдалить
  10. Зачем сразу «своими силами»? Есть ведь специальные ребята вроде меня, которые за совсем небольшую плату придут и всё сделают как надо.

    Тут ещё какой ведь нюанс. Компания-то зарабатывает на продаже ПО, а вот мне платят за количество часов, проведённых у заказчика. Сами понимаете, что если все заказчики решат ждать со внедрением новых версий, то я рискую остаться без куска хлеба с маслом и икрой.

    ОтветитьУдалить

Примечание. Отправлять комментарии могут только участники этого блога.