Миграция с ESX 3.5i на vSphere

Решил однажды diz поменять архитектуру своей инфраструктуры: с локальных дисков переехать на общее хранилище, построить простенькую SAN, апгрейднуть серваки.

Итак, “Миграция с ESX 3.5i на vSphere, или diz и Mister Nobody встают на грабли”.
Так как с деньгами напряги, то выбивать хранилище IBM DS3400 с должника начали еще в мае, в конце концов, пообещали его в декабре. Но поставщики, как обычно, задержали поставку, и пришло оно попозже. Во время ожидания прихода решили поменять процессоры и память в наших серверах Intel S5000VSA. Чтоб не встать на грабли diz посмотрел таблицу совместимости и понял, что на грабли уже встал производитель  и не все материнские платы одинаково полезны, поэтому процессоры Xeon 5110 смогли обновить только до Xeon 5345, так как несовместимостью с Xeon 54хх страдают все старые материнки, в том числе HP, IBM,…, зато через месяц на эти грабли встали наши товарищи. Если мы с процом не встали, то встали с памятью: подозрительно дешевая память с почти совпадающей маркировкой оказалась не та, пришлось доплатить и искать память с полной маркировкой из HCL. Это было в январские праздники.

В  конце января мы сходили и притащили DS3400, 4 HBA Qlogic и 4 LC-LC кабеля. За неделю до операции включили полку и настроили её. Как раз в это же время пришла правильная память на замену. Подключение серверов запланировали на среду с утреца, выбрали наименее важный сервер, предупредили заинтересованных лиц. В 8:30 забэкапили виртуалки, в 9:10 выключили сервак. Воткнули HBA, соединили кабелем, включили сервер – получили фигу, сторадж и сервер не видят друг друга, соединение делали Direct, стали думать, чего не работает – все коммутации перекоммутировали – ничего, достали всё из сервака, оставили только HBA – ничего. Выдвинули две версии – кабель, и прошивка. diz ушел за кабелями, я научился прошивать 4 HBA за 20 минут ;). Но тут, примерно в 10:30, залетели 4 товарища с выражением лица “Убьём гадов” и сказали, что сервачок один очень важный лежит, оказалось, что там работает DNS, на который стоит редирект, который мы просили убрать месяц назад. В ответ на яростную атаку diz схватил, на всякий случай, отвёртку, которой успешно отмахался ;), точнее прикрутил планку крепления к HBA.

Новые кабели подошли, оказалось нужны нам 50/125, а поставщик сэкономил и заменил на другие. Уфф, всё заработало. ESXi 4 решили разместить как SAN boot. Пока настраивали я понял какое зло BIOS контроллеров: bios материнской платы+рейда Adaptec+HBA QLogic суммарно создают примерно 5-минутный лаг загрузки и когда их надо настроить 3-4 раза начинаешь вешаться, понимая, что куча движений нужна только для смены источника загрузки.

Гипервизор разместили на хранилище, запустили с локального хранилища виртуалки, стали думать – как двинуть работающие ВМ с другого серверов, такого же Intel S5000VSA? Придумали использовать iSCSI сторадж на простой машине в качестве посредника и Storage VMotion. Поставили vCenter 4, подключили хосты, и двинули. Пришлось несколько часов смотреть бегущие процентики, хорошо хоть ночью не снились.

В четверг решили добавить HBA в освобожденный от виртуалок хост. В первый мы запихали целиком новую память Kingston, оттуда достали Samsung. Втыкаем все плашки Samsung, а получаем 8 ГБ вместо ожидаемых 16. Начинаем разбираться, оказалось у двух плашек из 8 на одну циферку отличается маркировки, втыкаем парно в разные каналы, вуаля, всё заработало. Остальные работы были проведены по накатанному пути.

Остался третий сервер IBM x3650 с Xeon 5405, diz ночью подключился и волшебным способом перенёс оттуда виртуалки на готовые хосты. Волшебный способ – это Motion выключенных виртуалок в vSphere, прелесть его в том, что он может тащить между хранилищами по сети, так что нам не пришлось использовать посредника в виде iSCSI-хранилища, а напрямую двинуть из доступного локального в недоступное хосту-источнику общее хранилище.

Наконец, все три наших хоста были готовы, возникла проблема, как переносить ВМ с процессоров Xeon 5345 на 5405, пришлось вспомнить про CPU Masking, что удалось тоже не сразу, но, немного поразбиравшись, всё получилось, но пришлось выбирать ВМ, которые можно было выключить для смены настроек.

Мониторинг DS3400 выявил новую проблему, так как один сервер подключен к обоим сторадж-процессорам, а два по одному пути к разным, то начался беспредел в борьбе за владение LUNами, сторадж сыпал ошибками, пришлось временно отрубить один сервер, чтобы всё выдавалось через один. Теперь планируем докупить пару FC-коммутаторов и пару HBA.

Несколько машин проапгрейдили до VM-HW 7, IP-шники послетали. И одну затащили 4-ым Convereter’ом, только исходный сервер выключали вручную.

Резюме по граблям:

  • Внимательно читайте HCL, подвохи могут быть в любом месте, в данном проекте мы попали на несовместимость процессоров и памяти с материнскими платами. Сейчас рассматриваем блейд-центр IBM BC-E, там вообще старых блоков питания на 2000 Вт не хватает на полный набор новых лезвий, а если комбинировать старые и новые, то хана.
  • Контролируйте поставку,  мы попали на сроки и на левые оптические кабели.
  • Аккуратно следите за правильностью архитектуры решений, мы криво сделали SAN, правда на нормальный нужны затраты.

Несколько рекомендаций:

  • Используйте vCenter 4 даже для управления ESX3.5 хостами, это просто удобней и местами функциональней, для полноценной работы надо будет оставить только сервер лицензирования и его указать в настройках лицензий vCenter 4.
  • Converter 4 просто сказка. Must try.
Запись опубликована в рубрике 4.1, VMware, vSphere с метками . Добавьте в закладки постоянную ссылку.

22 комментария на «Миграция с ESX 3.5i на vSphere»

  1. Alexander E. Vasilev говорит:

    От себя добавлю про косяк с CPU. на моих HP DL380 G5 на старых ревизиях матери CPU 51xx нельзя проапгрейдить на ЛЮБЫЕ 4-х ядерные процы, включая 53xx. Так что в этом плане Mister-у Nobody повезло больше чем мне

  2. Alexander E. Vasilev говорит:

    И к слову. Для временного общего хранилища-посредника можно также использовать виндовый NFS сервер. Работает на ура.

  3. Anton Zhbankov говорит:

    >ESXi 4 решили разместить как SAN boot.

    Удалось? Вообще это не поддерживается.

    >переносить ВМ с процессоров Xeon 5345 на 5405, пришлось вспомнить про CPU Masking

    EVC – великое изобретение!

  4. Mister Nobody говорит:

    >Удалось? Вообще это не поддерживается.
    Этот вопрос уже задается третий раз по этому проекту.
    Дружно читаем http://kb.vmware.com/kb/1015000
    Boot from SAN – VMware ESXi supports boot from SAN. Booting from SAN requires one dedicated LUN per server.

    >EVC – великое изобретение!
    Как я понял он только для современных процессоров Xeon 55хх+, рад буду ошибаться. Пойду еще раз вкурю мануал.

  5. diz говорит:

    >Удалось? Вообще это не поддерживается.
    От себя добавлю, что с SAN Boot все прошло просто на УРА, не было абсолютно ни каких подводных камней, хотя я больше всего опасался именно за эту часть.

    В части настроек СХД ориентировались на замечательные статьи специалистов тринити http://blog.trinitygroup.ru/search/label/DS3000 и драфт последнего “IBM Midrange System Storage Implementation and Best Practices Guide” http://www.redbooks.ibm.com/redpieces/abstracts/sg246363.html?Open

    У IBM есть еще “VMware Implementation with IBM Midrange System Storage” http://www.redbooks.ibm.com/redpieces/abstracts/redp4609.html?Open
    Но мне она показалась ни о чем 🙂

  6. phily говорит:

    EVC работает с Core 2 Duo даже и не Xeon тоже.
    У меня он не поднят, так как ручной маскинг меньше отключает функций (в KB есть 3 статьи, там все супер написано). И не надо говорить что SSE 3 никому нафиг не упал под ESX. Я в курсе.

    ESX и на atom ставится. Слово – работает я не стану употреблять.

    Чего-то у вас какой-то странный мграйшен план. По-моему, вы сами граблей себе наложили. Зачем апгрейдить железо вместе переездом на Vsphere? По-моему, нужно сначала было разобраться с железом, а потом уже мигрировать на Vsphere, тем более, что можно было не отключать ни одной виртуалки.
    Локальные хранилища можно отшарить 3-мя способами, минимум!
    И все было бы тихо, чинно, благородно 🙂
    И чего ты меня не спросил?

  7. Mister Nobody говорит:

    Чтобы начать миграцию нужен был вицентр, а чтоб поставит его нужна была оперативная память ;), а её не поставили одновременно с процами. 😉

  8. Anton Zhbankov говорит:

    >Как я понял он только для современных процессоров Xeon 55хх+

    Для 53xx+. Точнее для Core 2 и выше.

  9. Mister Nobody говорит:

    По EVC
    1. Это настройка кластера, его еще не создавали
    2. Создал чисто EVC кластер
    3. При добавлении хоста ругается, говорит не могу добавить хост, проверьте настройки бивиса, хм…

    Если виртуалки уже стартнуты, то после создания EVC их надо ребутить?

  10. Anton Zhbankov говорит:

    >Дружно читаем http://kb.vmware.com/kb/1015000

    Значит начали поддерживать.

  11. Anton Zhbankov говорит:

    В 4.0u1 EVC можно включить вместе с виртуалками. Главное – начать создание кластера с хостов с самым старым поколением процессоров. Но запущенные на новых хостах придется таки выключать.

  12. phily говорит:

    А для тех у кого “старички 30ХХ в строю” и пара новых 5500 и которым EVC откидывает все к режиму Core2 Duo – читаем http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1993 про маскинг.

    Учтите, что там где пишут “0” в строчках нужно писать “X” латинское и заглавное. С нулем не работает. Про причину этого я пытаюсь узнать.

    Большинству поможет vpxd.cfg, который отключает SSE 4.1

    —-:—-:—-:X—:—-:—-:—-:—-

    true
    256
    256

    true

    30

  13. phily говорит:

    Конфиг не могу выложить он xml.
    Поэтому напишу статью, там он будет 😉

  14. Андрей Вахитов говорит:

    2Phily: а что за способы отшаривания локальных стораджей?

  15. Anton Zhbankov говорит:

    Андрей, наиболее очевидный из них – микро ВМ с линуксом, поднятым NFS/iSCSI и диском на весь локальный сторадж.

    Чуть менее очевидный – то же самое, но еще heartbeat и DRBD для репликации.

  16. Андрей Вахитов говорит:

    Уговорил 🙂
    Один способ в зачет. А остальные?

  17. phily говорит:

    Starwind, Lefthand, xtravirt
    Это с ходу пришло в голову.

  18. Anton Zhbankov говорит:

    ex-XtraVirt aka PHDVirtual Virtual SAN == linux + iSCSI + heartbeat + drbd

  19. A.Vakhitov говорит:

    Дык это одно и то же 🙂
    По сути, VSA, выдающее на гора NFS/iSCSI.
    Я-то думал о каких-то экзотичных извращениях вроде локальных RDM или копирования файлов через FTP/SCP…

  20. phily говорит:

    Ну, есть один вариантик 🙂
    Итак, делаем локальный RDM на каждом серваке и если у вас полный ESX монтируем его как NTFS. На этом RDM держим виртуалки.
    Плюс самбой раздаем другим сервакам доступ.
    тут некоторые процедуры как это делать http://blogs.lankey.ru/2009/08/17/backup_vmware_esx_to_usb_hdd/
    Хотя это совершенно бредовая тема и только для тестов!

  21. dim-soft говорит:

    ух ты
    а если просто конвертером в “горячую” перенести ?
    у меня получалось по 1Gb/s сети 1 Тб за 17 часов

  22. Андрей Вахитов говорит:

    Сервисы с постоянно изменяющимися данными не подходят для конвертации на горячую.
    Примеры – контроллер домена, почтовый сервер, сервер СУБД…

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *