Краш-тест облачной платформы высокой доступности

в 6:56, , рубрики: Блог компании ИТ-ГРАД, виртуализация данных, виртуализация серверов, ИТ-ГРАД, ит-инфраструктура, облака, облачная площадка, Облачные вычисления, облачные сервисы, облачные услуги, облачный сервер, сетевое обборудование

Краш-тест новой облачной площадки IT-GRAD

Как убедиться в том, что инфраструктура облачного провайдера действительно не имеет единой точки отказа?
Проверить это на деле!
Здесь я расскажу о том, как мы проводили приёмо-сдаточные испытания нашей новой облачной площадки.

Предыстория

24 сентября мы открыли новую публичную облачную площадку в Санкт-Петербурге:
www.it-grad.ru/tsentr_kompetentsii/blog/39/

Предварительный план испытаний облачной платформы:
habrahabr.ru/post/234213/

И вот мы приступаем…

Удаленное тестирование

1. Поочередное выключение контроллеров FAS8040

Поочередное выключение контроллеров FAS8040

Ожидаемый результат Фактический результат
Автоматический takeover на рабочую ноду, все ресурсы VSM должны быть доступны на ESXi, доступ к датасторам не должен пропадать. Наблюдали успешный автоматический takeover одной «головы» (затем и второй). Тома от первого контроллера успешно перешли на обслуживание второго, примечательно, что сама процедура заняла какие-то десятки секунд (включая обнаружение отказа «головы»).
На нодах выставлены показатели: options cf.takeover.detection.seconds 15

Краш тест облачной платформы высокой доступности

2. Отключение всех Inter Switch Link между свичами CN1610

Отключение всех Inter Switch Link между свичами CN1610

Ожидаемый результат Фактический результат
При отключении всех Inter Switch Link между свичами CN1610 связь между нодами не должна прерываться. Соединение между хостом и сетью не пропадало, доступ к ESXi осуществлялся по второму линку.

Краш тест облачной платформы высокой доступности

3. Поочередная перезагрузка одного из парных кластерный свичей и одного из Nexus’ов

Поочередная перезагрузка одного из парных кластерный свичей

Поочередная перезагрузка одного из Nexus

Ожидаемый результат Фактический результат
Нет сбоев в работе кластера NetApp Контроллеры NetApp остаются собранными в кластер через второй свитч CN1610. Дублирование кластерных свитчей и линков до контроллеров позволяет безболезненно переносить падение одной железки CN1610.
Один из портов на нодах должен оставаться доступным, на IFGRP интерфейсах на каждой ноде должен оставаться доступен один из 10 GbE интерфейсов, все ресурсы VSM должны быть доступны на ESXi, доступ к датасторам не должен пропадать. В результате дублирования линков и объединения их в Port Channels, перезагрузка одного из Nexus 5548 не вызвала никаких эмоций.

Перезагрузка одного из Nexus не вызвала никаких эмоций

Краш тест облачной платформы высокой доступности

4. Поочередное гашение одного из vPC (vPC-1, vPC-2) на Nexus

Поочередное гашение одного из vPC (vPC-1 или vPC-2) на Nexus

Ожидаемый результат Фактический результат
Моделирование ситуации, когда одна из нод NetApp теряет сетевые линки. В данном случае взять на себя управление должна вторая «голова». Были загашены, соответственно: e0b и e0c интерфейсы контроллера, за ними перешли в состояние «down» ifgrp a0a и поднятые на ней VLANs. После чего нода ушла в обыкновенный тейковер, о нем мы знаем из первого теста.

Поочередное гашение одного из vPC (vPC-1 или vPC-2) на Nexus

Краш тест облачной платформы высокой доступности

5. Поочередное отключение Inter Switch Link между коммутаторами Cisco Nexus 5548

Поочередное отключение Inter Switch Link между коммутаторами Cisco Nexus 5548

Ожидаемый результат Фактический результат
Сохранение связанности между коммутаторами. Интерфейсы Eth1/31 и Eth1/32 собраны в Port Channel 1 (Po1). Как видно из скриншота ниже, при падении одного из линков, Po1 остается активным и не происходит потери связности между коммутаторами.

Поочередное отключение Inter Switch Link между коммутаторами Cisco Nexus 5548

Краш тест облачной платформы высокой доступности

6. Поочередное жесткое отключение ESXi

Поочередное отключение ESXi

Мы выключили один из рабочих ESXi-хостов, на котором в момент выключения находились тестовые машины разных ОС (Windows, Linux). Отключение эмулировало состояние падения рабочего хоста. После срабатывания триггера недоступности хоста (и виртуальных машин на нем), начался процесс перерегистрации ВМ на второй (рабочий) хост. Затем ВМ успешно на нем запустились в течение нескольких минут.

Ожидаемый результат Фактический результат
Перезапуск виртуальных машин на соседнем хосте. Как и ожидалось, после отработки HA VMware машинки перезапустились на соседнем хосте в течение 5-8 минут.

Краш тест облачной платформы высокой доступности

7. Слежение за отработкой мониторинга

Ожидаемый результат Фактический результат
Получение сообщений об ошибках. Что тут говорить… Наполучали множественные рассылки errors и warnings, система заявок и обращений обработала нотификации по шаблонам, servicedesk реагировал безукоризненно.

Система мониторинга истошно спамила в Service Desk.

Падение хоста ESXi и обработка такого алерта в инцидентной системе

ITSM система разбирала эти письма по шаблонам и создавала события. На основе одинаковых событий автоматически комплектовались инциденты. Вот один из инцидентов, который был создан ITSM системой на основе событий в системе мониторинга.

Краш тест облачной платформы высокой доступности

Один из таких инцидентов упал и на меня.

Падение хоста ESXi и обработка такого алерта в инцидентной системе

Краш тест облачной платформы высокой доступности

Тестирование непосредственно на стороне оборудования

Приемо-сдаточные испытания облачной площадки

1. Отключение кабелей питания (все единицы оборудования)

Ничего нового, если, конечно, у вас не обнаружится, что один из блоков питания — сбойный.
В течение всего испытания ни одна железка не пострадала.
А NetApp отписался и за себя, и за Cluster Interconnect свитчи:

Отключение кабелей питания

На Cluster-Net свитче:

Отключение кабелей питания

В VMware vSphere ошибки хостов:

Ошибки хостов в VMware vSphere

Замечание: Менеджмент свитч Cisco SG200-26 не имеет резервирования питания.
Данный коммутатор задействован в менеджмент сети доступа (на управляющие порты систем хранения, серверов). Отключение питания на этом коммутаторе не повлечет за собой простоев клиентских сервисов. Также выход из строя Cisco SG200-26 не приведет к потере мониторинга, так как мониторинг доступности инфраструктуры осуществляется через менеджмент сеть, которая образуется на уровне Cisco Nexus 5548. Управляемый свитч логически стоит за ним и служит ТОЛЬКО для доступа на консоль управления оборудованием.
И все-таки, чтобы избежать потери управления через данный свитч, ему на помощь уже закуплен Automatic Transfer Switch (Автомат Ввода Резерва) APC AP7721, который обеспечивает избыточность питания от двух шин.

Краш тест облачной платформы высокой доступности

2. Поочередное отключение сетевых линков от ESXi (Dell r620/r810)

Сетевое подключение к серверу ESXi

Соединение между хостом и датасторой не пропадало, доступ к ESXi осуществлялся по второму линку.

Краш тест облачной платформы высокой доступности

Вот и всё. Все тесты прошли успешно. Приёмо-сдаточные испытания сданы. Аппаратная часть облака готова к развертыванию виртуальной инфраструктуры для новых клиентов.

PS
После проведения тестов меня долго не отпускало ощущение мощи и добротности надежного железа, которое мне довелось пощупать своими руками в ходе проверки всего комплекса на отказоустойчивость.

Автор: it_man

Источник

Поделиться

* - обязательные к заполнению поля