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

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

Сьют ИТ-ГРАДа в SDN

24 сентября мы (ИТ-ГРАД) открыли новую публичную облачную площадку в дата-центре SDN (Stack Data Network). Перед вводом первого клиента в промышленную эксплуатацию я занимаюсь планированием испытаний, которые покажут, что все компоненты работают как задумывалось, а дублирование и обработка аппаратных сбоев происходит в штатном режиме. Здесь я расскажу о тех тестах, которые уже запланировал, а также попрошу поделиться своими дополнениями и рекомендациями.

Немного о наполнении новой площадки:

На первом этапе в новый ЦОД была установлена система хранения данных NetApp FAS8040 (мы как золотой партнер компании NetApp – остаемся верны вендору), система пока имеет 2 контроллера FAS8040, которые собраны в кластер через дублируемые 10Gbit/s коммутаторы (Cluster Interconnects) и позволяют наращивать кластер СХД до 24 контроллеров. Контроллеры СХД в свою очередь подключены к сети ядру сети по 10Gbit/s оптическим линкам сформированное двумя коммутаторами Cisco Nexus 5548UP с поддержкой L3.

Серверы гипервизоров VMware vSphere ESXi (Dell r620/r820) подключаются к сети по двум интерфейсам 10Gbit/s, используя конвергентную среду передачи данных (для работы с дисковым массивом и сетью передачи данных). Пул ESXi серверов образует кластер с поддержкой VMware vSphere High Availability (HA). Менеджмент интерфейсы серверов iDRAC и контроллеров СХД собираются на отдельном выделенном коммутаторе Cisco.

Когда базовая настройка инфраструктуры завершена, приходит время остановиться и оглядеться назад: ничего не забыли? все ли работает? надежно??? Задел на успех в лице опытных инженеров мы уже имеем, но чтобы «фундамент» оставался крепким, необходимо, конечно же, правильно провести испытания на стрессоустойчивость инфраструктуры. Успешное окончание тестов будет свидетельствовать о завершении первого этапа и сдачи приемо-сдаточных испытаний (ПСИ) новой облачной площадки.

Итак, озвучу исходные данные и план тестирования. А внимательные читатели могут внести предложения/рекомендации/пожелания по коррекции возможных моментов, которые мы могли не предусмотреть. С радостью их выслушаю.

Исходные данные:

  • FAS8040 dual controller под управлением Data ONTAP Release 8.2.1 Cluster-Mode
  • Дисковые полки NetApp DS2246 (24 x 900GB SAS) – 5 шт.
  • NetApp FlashCache 512Gb – 2шт.
  • NetApp Clustered Ontap CN1610 Interconnect Switch – 2 шт.
  • Коммутаторы ядра унифицированной сети Cisco Nexus 5548 – 2 шт.
  • Пограничный роутер Juniper MX80 (пока один, второй ещё не приехал)
  • Управляемый коммутатор Cisco 2960
  • Сервера Dell PowerEdge R620/R810 with VMware vSphere ESXi 5.5

Схема подключения выглядит следующим образом:

Схема подключения

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

Итак, условно наши «краш-тесты» можно поделить на 3 вида:

  • Тестирование дискового массива FAS8040
  • Тестирование сетевой инфраструктуры
  • Тестирование виртуальной инфраструктуры

При этом тестирование сетевой инфраструктуры в нашем случае выполняется в укороченном варианте по причинам, которые указывались выше (не все сетевое оборудование установлено).

Перед тестами планируется ещё раз сделать бэкапы конфигураций сетевого оборудования и массива, а также проанализировать результаты дискового массива с помощью Config Advisor.

Теперь расскажу подробнее о плане тестирования.

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

  1. Поочередное выключение контроллеров FAS8040.
    Ожидаемый результат: автоматический takeover на рабочую ноду, все ресурсы VSM должны быть доступны на ESXi, доступ к датасторам не должен пропадать.
     
  2. Поочередное отключение всех Cluster Link одной ноды.
    Ожидаемый результат: автоматический takeover на рабочую ноду, либо перемещение/переключение VSM на доступные сетевые порты на второй ноде, все ресурсы VSM должны быть доступны на ESXi, доступ к датасторам не должен пропадать.
     
  3. Отключение всех Inter Switch Link между свичами CN1610.
    Ожидаемый результат: предполагаем, что кластерные ноды будут доступны друг для друга через cluster links одного из Cluster Interconnect (в связи с перекрестным соединением NetApp — Cluster Interconnect).
     
  4. Перезагрузка одного из Nexus.
    Ожидаемый результат: один из портов на нодах должен оставаться доступным, на IFGRP интерфейсах на каждой ноде должен оставаться доступен один из 10 GbE интерфейсов, все ресурсы VSM должны быть доступны на ESXi, доступ к датасторам не должен пропадать.
     
  5. Поочередное гашение одного из vPC (vPC-1 или vPC-2) на Nexus.
    Ожидаемый результат: перемещение/переключение VSM на доступные сетевые порты на второй ноде, все ресурсы VSM должны быть доступны на ESXi, доступ к датасторам не должен пропадать.
     
  6. Поочередное отключение Inter Switch Link между коммутаторами Cisco Nexus 5548.
    Ожидаемый результат: Port Channel активен на одном линке, нет потери связности между коммутаторами.
     
  7. Поочередное жесткое отключение ESXi.
    Ожидаемый результат: отработка HA, автоматический запуск ВМ на соседнем хосте.
     
  8. Слежение за отработкой мониторинга.
    Ожидаемый результат: получение нотификаций от оборудования и виртуальной инфраструктуры о появившихся проблемах.
     

II. Непосредственно на стороне оборудования

  1. Отключение кабелей питания (все единицы оборудования).
    Ожидаемый результат: оборудование работает на втором блоке питания, нет проблем с переключением между блоками.
    Замечание: Менеджмент свитч Cisco не имеет резервирования питания.

     
  2. Поочередное отключение сетевых линков от ESXi (Dell r620/r810).
    Ожидаемый результат: ESXi доступен по второму линку.
     

Ну вот и все, жду ваших комментариев.

Автор: it_man

Источник

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


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js