How we’ve updated 850 vCenter in 4 weeks

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

С 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 KB, чтобы уведомлять клиентов о проблемах, с которыми мы столкнулись, и которые были признаны VMware ошибками. Команды провели много ночей, чтобы обеспечить минимальное влияние доступности vSphere для клиентов.

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

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

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


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


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


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

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

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