Как мы обновили 850 vCenter за 4 недели

Управление выпусками корпоративного программного обеспечения — непростая задача: обновление инфраструктуры, борьба с опасениями, что редактор программного обеспечения их не поддержит, обновление лицензий для совместимости с новыми версиями и принятие всех мер предосторожности для отката, если что-то не работает должным образом. ожидается…

С OVH Private Cloud мы избавляем вас от этой сложности. Мы управляем этим трудоемким и стрессовым аспектом, чтобы вы могли сосредоточиться на своем бизнесе и производстве.

Но это не значит, что это не проблема для нас.



Обновление сотен vSphere 5.5 до 6.0

vSphere — это ведущий продукт предложения Private Cloud, он является частью пакета SDDC, предоставляемого VMware. vSphere — это программное обеспечение, позволяющее пользователю управлять своими хостами, хранилищем, сетью… Через клиента он может создавать кластеры с этими активами для надежного, стабильного и высокодоступного размещения производственной среды.

С сентября 2018 года поддержка vSphere (vCenter, ESXi…) версии 5.5 со стороны VMware прекращается. Обладая безопасностью и стабильностью инфраструктуры частного облака, мы начали процессы обновления для всех vCenter.



У нас было около 850 vCenter в версии 5.5 в производстве, что представляет собой значительную работу по обновлению всего, если она выполняется вручную. Но в OVH у нас есть общий лейтмотив: автоматизировать все человеческие действия  для повышения эффективности и избегать ошибок.

Так нам удалось обновить 850 vCenter с версии 5.5 до версии 6.0 за 4 недели. Другими словами, более 210 vCenter в неделю, 30 vCenter в день , с командой из 10 человек, выполняющих это обслуживание в фоновом режиме, без какого-либо влияния на производительность клиентов.

Наша команда разработчиков разработала и создала набор скриптов (которые мы внутри себя называем «роботом») для автоматизации обновлений vCenter несколько лет назад. Этот робот сильно изменился с момента появления продукта Private Cloud и следует за нами с версии 4.1 до 6.5, работа над которой еще продолжается.

Мы столкнулись с множеством проблем при настройке автоматических действий, таких как повреждение базы данных, службы, не интегрированные в систему единого входа (было очень сложно управлять им в версиях 5.0 и 5.1), а также отпечаток, который не обновлялся для всех служб., очень сложно устранить неисправность и воспроизвести ее. У нас даже были некоторые операционные системы, которые блокировали обновления программного обеспечения, из-за чего все было жестко остановлено.

Наши операционные группы много работали с группой поддержки VMware, чтобы найти обходные пути для возникающих проблем и автоматизировать их с помощью команды разработчиков. Это привело к созданию базы знаний VMware для уведомления клиентов о проблемах, с которыми мы столкнулись и которые были признаны VMware ошибками. Команды провели много ночей, чтобы обеспечить минимальное влияние доступности vSphere для клиентов.

Обновление апгрейдера: новая версия робота

Все эти проблемы убеждают нас действовать по двум причинам. Во-первых, запустите новую версию робота обновления , создавая меньше ошибок, имея более быстрое выполнение с точки зрения клиента, более надежное и надежное. Во-вторых, мы отказались от процесса обновления по умолчанию с использованием обновления программного обеспечения VMware для решения, в котором мы начинаем со только что установленного обновленного стека vCenter на обновленной виртуальной машине, а затем повторно подключаем все компоненты (базу данных, NSX…) к этому новому vCenter. .

Это значительно повысило стабильность наших услуг, поскольку мы обеспечиваем новую работоспособную и обновленную основу для vCenter. Все это резко сократило количество вмешательств наших SRE в инфраструктуры частного облака.

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

Мы создали этого робота для обновления в роботе-оркестраторе, который, в соответствии с введенными параметрами, будет создавать задачи обновления для каждого частного облака, связанного с обслуживанием, и будет планировать его в автоматические даты в течение как минимум 72 часов с учетом рассмотрения клиента. но также количество запускаемых обновлений по часам и критическим периодам (например, Черная пятница или Зимние распродажи). Клиенты могут изменить расписание своих обновлений с помощью диспетчера в части «Операции», чтобы выполнить обслуживание в более удобное для их производства время.



Наши команды SRE следят за роботами и следят за тем, чтобы техобслуживание выполнялось должным образом и в запланированное время.






Подводя итоги, мы перешли от необходимости автоматизировать операцию обновления vCenter, которая должна занимать не менее 12 часов на каждый vCenter, к первой версии автоматизации, которая позволяет выполнить эту операцию за 4 часа, но с слишком высокий уровень ошибок (20%) из-за повторяющихся ошибок, которые SRE приходилось исправлять вручную. Теперь вторая версия является прочной, надежной и стабильной , позволяющей избежать известных проблем и создавать только редкие и уникальные проблемы, которые будут исправлены в процессе автоматизации на тщательно подобранном этапе.

Что дальше?

В ближайшие месяцы последуют другие мероприятия по техническому обслуживанию, обновление хоста с версии 5.5 до версии 6.0, обновление нашей опции Veeam Backup с 8.0 до версии 9.5, обновление нашей опции Zerto с 5.0 до 5.5 и множество других обновлений наших внутренних машин. для обеспечения регулярного аудита PCI-DSS.

Мы сохраним ту же прозрачность и коммуникацию , пока мы прислушиваемся к вашим отзывам и улучшаем нашу систему обслуживания.

0 комментариев

Оставить комментарий