Всем доброго времени суток! Мы — Руслан Алиев, главный эксперт, и Михаил Калганов, начальник отдела вычислительных комплексов Лаборатории R&D «РТК-ЦОД». Наш отдел проводит испытания различного вычислительного оборудования и программных решений для дата-центров компании — на сегодня их 27, так что работы хватает.
Коротко о нас
Лаборатория R&D — устоявшийся вариант названия управления исследований и разработок новых решений в «РТК-ЦОД». Лаборатория появилась шесть лет назад в одном из московских дата-центров нашей компании. В те далекие времена в распоряжении большой команды из трех сотрудников была целая одна стойка, и мы испытывали различное российское оборудование и ПО на предмет применимости в наших проектах. Работа тогда не то, чтобы кипела, ведь применение отечественных решений не было столь критически важным, как в наши дни для крупных компаний, в частности, госсектора. Подробнее о раннем периоде существования Лаборатории R&D можно узнать из статьи ее создателя и руководителя Александра Власова.
С провозглашением курса на импортозамещение рынок отечественных ИТ-решений вступил в фазу бурного и беспрецедентного роста. С одной стороны, такое разнообразие приятно радовало — ведь можем же, когда захотим — а с другой, слегка обескураживало: как определить, что из всего этого действительно применимо и будет надежно работать в том числе в конкретном сценарии или при жестких архитектурных ограничениях?
Почему мы не тестируем, а испытываем?
Мы считаем, что термин «тестирование» больше подходит ситуациям, когда тестировщик идет по скрипту, нажимает на разные кнопочки и проверяет, выполнилась ли задача, фиксируя успех или неудачу. Испытания же — это полноценное исследование, как оборудование ведет себя в разных условиях, выяснение причин отклонения от нормы. Обязательно с постоянной обратной связью производителю и требованиями устранить выявленные недостатки.
Мы всегда проводим большое техническое исследование, чтобы получить полное представление о качестве и применимости объекта испытаний в конкретных режимах работы, сценариях и условиях. Полноту исследования можно сравнить с госприемкой: тщательная подготовка и сбор согласований порой могут занять месяц. Во время испытаний мы подробно фиксируем все особенности и нюансы поведения продукта, а также малейшие расхождения показателей с ожидаемыми значениями. Результаты исследования предоставляем в формате подробного отчета объемом более 100 страниц: описываем полученные результаты, условия проверки и обнаруженные особенности продукта.
Зачем все-таки мы это делаем?
Расскажем по секрету Полишинеля: не все российские системы хранения данных (СХД) уже достигли уровня качества своих заграничных конкурентов. Те проблемы, с которыми сейчас сталкиваются отечественные вендоры, ведущие мировые производители успешно решили еще много лет назад. Тем не менее, мы в Лаборатории радуемся постепенному исчезновению разницы в подходах к работе между западными и российскими вендорами, поскольку наблюдаем его с каждым новым релизом СХД. Производители устраняют ранее выявленные ошибки, выстраивают процессы работы с заказчиками, но, на наш взгляд, им есть к чему стремиться. Например, стоит довести до ума калькуляторы производительности, уделять больше внимания документации. А повысить прозрачность продаж и процессов техподдержки стоило бы как можно быстрее.
Чтобы выявить всевозможные недостатки, мы испытываем оборудование российских производителей в условиях, имитирующих реальную рабочую нагрузку в различных режимах, которые максимально приближены к продуктивной среде. Проведя 100500 исследований классических систем хранения данных, мы с уверенностью заявляем: внедрение в проекты «РТК-ЦОД» отечественных СХД без предварительных испытаний привело бы к критичным проблемам на проектах.
Но прежде, чем перейдем к нашему опыту, немного теории. Классические системы хранения данных имеют особую архитектуру и поддерживают различные режимы работы. Если коротко, то эти режимы можно разделить на следующие три типа:
Active-Passive
Один из контроллеров назначен основным и выполняет задачи с данными. Второй находится в режиме ожидания и выполняет единственную функцию — в случае сбоя основного контроллера ему предстоит обеспечить непрерывную работу системы. Основной недостаток такой архитектуры — неэффективное использование ресурсов контроллеров, ведь один из них почти всегда бездействует, ожидая возможного отказа основного.
Асимметричный доступ к логическим дискам (Asymmetric Logical Unit Access - ALUA)
При асимметричном доступе к виртуальным логическим томам (LUN) в режиме Active-Active используется протокол SCSI между LUN и двумя контроллерами. При этом один из путей становится оптимальным, а другой — как бы запасным. Если контроллер обращается к LUN по неоптимальному пути, производительность падает. Для максимальной производительности необходимо распределить пулы или тома между контроллерами равномерно, т.е. соответственно рабочим потокам. Хотя оба контроллера работают одновременно, при обновлениях или авариях начинаются проблемы. При миграции томов на второй контроллер возникают слишком длительные остановки ввода-вывода, что сказывается на работе прикладного ПО. Поэтому главная трудность для ИТ-специалистов в этом случае — балансировка рабочих потоков.
Симметричный режим Active-Active (Symmetric Active-Active - SAA)
В симметричном режиме работы контроллеров, называемом также Symmetric Active-Active, несколько инициаторов могут одновременно обращаться к одному LUN через два контроллера. В отличие от ALUA, SAA обеспечивает стабильность характеристик обоих контроллеров, функционирующих в одной связке, что включает балансировку нагрузки и доступ нескольких серверов к одному и тому же LUN, что дает существенный выигрыш в производительности и снижает время отработки отказа.
Для наших проектов мы рассматриваем и берем на испытания в основном только СХД с поддержкой режима Active-Active (симметричный SAA и ассиметричный ALUA).
Некоторые проблемы в работе систем хранения данных, которые могут возникнуть в процессе эксплуатации, заключаются в низкой производительности СХД, длительных задержках ввода-вывода при сбоях компонентов системы или в ходе плановых технических работ, трудностях с масштабированием и других аспектах. Основная задача испытаний — определение степени соответствия СХД требованиям проектов, в которых предполагается ее использовать.
Прежде чем продолжить, необходимо сделать несколько важных уточнений:
Наша методика испытаний не является статичной: она постоянно совершенствуется, и в нее вносятся важные изменения по запросам наших коллег, в частности, из службы эксплуатации;
Мы предпочли бы не раскрывать все детали проведения испытаний, поэтому изложим основные принципы и ключевые этапы.
Подготовка к испытаниям
Перед началом испытаний мы направляем производителю опросный лист со списком вопросов о функциональности СХД, ее характеристиках и других интересующих нас аспектах. Полученная информация позволяет получить первичное представление о возможностях системы и о степени ее потенциальной пригодности для наших проектов.
Тщательно проанализировав ответы в опроснике, мы принимаем решение о целесообразности проведения испытаний. Если решение положительное, производитель должен предоставить нам техническую документацию в объеме, достаточном для выполнения стандартных операций и диагностики возможных проблем. Если документация не соответствует требованиям к ее объему или качеству, мы отказываемся от проведения испытаний, поскольку это рассматривается как стоп-фактор для потенциальной эксплуатации.
На следующем этапе мы согласовываем спецификацию СХД, которая будет отправлена нам для испытаний, с учетом наших требований к ее составу.
Испытательный стенд
В нашей лаборатории есть несколько действующих стендов для выполнения испытаний СХД, на постоянной основе мы используем серверы на «голом железе» (bare metal) и платформу виртуализации Basis Dynamix. Также есть испытательный стенд на базе продуктов VMware — он не является предпочтительным, но мы расскажем про испытания СХД на примере именно этого стенда, поскольку продукты VMware исторически привычны и знакомы широкому кругу специалистов.
Для создания тестовой нагрузки на платформе виртуализации развернуты виртуальные машины под управлением Linux-подобной ОС. На виртуальных машинах установлен программный генератор синтетической нагрузки ввода-вывода VDBench. Каждая нагрузочная машина выполняет тестовые операции в 16 потоков, направленных на непосредственно выделенный для нее LUN. Минимальное количество виртуальных машин, необходимых для проведения испытаний — 4 штуки. Это число может увеличиваться в зависимости от конфигурации СХД и ее производительности. Каждая виртуальная машина оснащена 16 виртуальными процессорами (vCPU) и 16 ГБ оперативной памяти (RAM). Виртуальные машины, генерирующие нагрузку, располагаются на отдельной дисковой подсистеме, отличной от испытуемой СХД, что позволяет исключить возможное влияние СХД на их работу.
Ниже в таблице приведены минимальные требования гипервизоров кластера платформы виртуализации к машинам генератора нагрузки:
№ | Оборудование | Модель | Количество | Характеристики |
1 | Сервер–гипервизор | Server T2000 | 2 | CPU: Intel(R) Xeon(R) Gold 2.00GHz (Cores per socket: 12) RAM: 256 GB Fibre Channel 16Gb x 2 Ethernet 25Gb x 2 ПО: VMware ESXi (Build x.x.x) |
2 | Нагрузочная виртуальная машина | - | 8 | OS GNU/Linux Kernel Linux x.xx.x.xx-amd64 vCPU 16, RAM 16GB, HDD 200GB |
3 | ПО генератора рабочей нагрузки ввода-вывода | - | 8 | VDBench v.5.04.07 |
Конфигурация серверов виртуализации и нагрузочных ВМ
Нагрузочные испытания СХД мы проводим обязательно с использованием основных блочных протоколов доступа Fibre Channel (FC) и iSCSI. В зависимости от специфики проекта также осуществляются нагрузочные тесты по дополнительным протоколам, таким как iSER, RoCEv2 и NVMEoF.
Настройка стенда для проведения испытаний по протоколу FC
При испытаниях СХД по протоколу FC мы исходим из следующих принципов:
Для сетевой связности СХД с нагрузочными серверами по протоколу FC требуется не менее двух SAN-фабрик на FC-коммутаторах;
Каждый сетевой адаптер FC, серверов нагрузки и СХД подключен к двум FC- фабрикам по разным портам, тем самым поровну распределяя передачу данных между FC-фабриками;
Изоляция трафика, ограничивающего видимость устройств (инициаторов и таргетов) настроена по наиболее оптимальному варианту: «один инициатор — много таргетов» (Single Initiator Zoning) с использованием WWN (World Wide Name). Это предотвращает проблемы, когда серверы (инициаторы) видят чужие виртуальные логические тома (таргеты). В отдельных случаях — либо если так рекомендует производитель СХД, либо по другим причинам — может быть использована иная схема настройки зон.
Далее мы организуем дисковое пространство СХД и создаем виртуальные логические тома (LUN), которые презентуются нагрузочным серверам и FC-инициаторам. После их презентации FС-инициаторам новые устройства хранения на гипервизорах ESXi назначаются виртуальным машинам генератора нагрузки в качестве блочного устройства типа RDM.
Настройка стенда для проведения испытаний по протоколу iSCSI
При испытаниях по протоколу iSCSI мы соблюдаем следующие принципы:
Организуем сетевую связность таргетов (СХД) и инициаторов (нагрузочных серверов) для обмена трафиком по протоколу iSCSI с помощью двух коммутаторов уровня L3, которые выполняют маршрутизацию трафика. На каждом из коммутаторов создаются две немаршрутизируемые VLAN, которые объединяются в один VRF;
VLAN распределены на Ethernet-порты контролеров СХД таким образом, что каждый сетевой адаптер контроллеров СХД подключен к обоим VLAN и коммутаторам разными портами. Пропускная способность портов СХД и коммутаторов — не менее 25G;
На стороне платформы виртуализации VMware, физические сетевые карты гипервизоров — они же vmnic* по терминологии VMware — объединены в централизованные интерфейсы Uplink c помощью распределенного коммутатора VDS (vSphere Distributed Switch).
Для организации доступа к LUN по протоколу iSCSI на VDS создаются две порт-группы. Каждая порт-группа привязана к одному Uplink и для изоляции сетевого трафика нагрузочных машин определена в отдельный VLAN. Для обмена трафиком на каждой порт-группе каждому гипервизору назначается VMkernel – адаптер со значениями параметра MTU в 9000.
Для работы с виртуальными логическими томами по протоколу iSCSI со стороны серверов виртуализации необходимо наличие iSCSI-инициатора с уникальным идентификатором типа IQN. На стороне СХД он служит для привязки сервера в качестве инициатора, что дает возможность СХД предоставлять разграниченный доступ к виртуальным логическим томам. Для этого, в свою очередь, мы добавляем программный iSCSI-адаптер на каждый гипервизор ESXi. В настройках каждого адаптера в разделе Dynamic Discovery добавляем IP-адреса портов СХД. После этого автоматически определяется соответствие этого IP-адреса iSCSI таргетам СХД — оно отображается в разделе Static Discovery. В разделе Network Port Binding выполняется привязка двух VMkernel Adapter для разрешения доступа к массиву iSCSI по нескольким путям:
Для всех L2 интерфейсов, применяемых в испытаниях, должно быть задано значение MTU стандартного размера, допускающего использование Jumbo Frame от 9014 до 9022 (т.е. 9000 + заголовки L2 6 SRC MAC + 6 DST MAC + 4 FCS +2 EtherType +4 DOT1Q на всех хостах и сетевом оборудовании, в т.ч. транзитном), без фрагментации сетевого пакета.
Значение MTU для всех L3 интерфейсов в испытаниях должно быть задано на уровне 9000.
Далее мы организуем дисковое пространство СХД и создаем виртуальные логические тома (LUN), которые презентуются нагрузочным серверам и iSCSI-инициаторам. После их презентации iSCSI-инициаторам новые устройства хранения на гипервизорах ESXi назначаются виртуальным машинам генератора нагрузки в качестве блочного устройства типа RDM.
Оптимизация многопутевого ввода-вывода (MPIO)
Проанализировав данные испытаний СХД, мы пришли к выводу: независимо от применяемого протокола передачи данных целесообразно использовать настройки MPIO, речь о которых пойдет чуть ниже.
Для оптимизации многопутевого ввода-вывода в среде гипервизоров ESXi для каждого обнаруженного виртуального логического тома следует установить политику Multipathing Policies: Round Robin. При использовании этой политики мы рекомендуем задать ограничение IOPS на уровне 1 (вместо стандартного значения 1000). Это подразумевает переключение путей для каждой операции ввода-вывода, что значительно снижает вероятность перегруза одного из путей и, как следствие, способствует повышению производительности IO. Кроме того, такая настройка сокращает время, необходимое для переключения пути в случае недоступности порта сетевого адаптера, коммутатора или системы хранения данных. Указанные параметры могут быть заданы с помощью следующей команды в консоли гипервизора ESXi:
for i in esxcfg-scsidevs -c |awk '{print $1}' | grep naa.600xxxxxxxxxxxxxxxxxx; do esxcli storage nmp psp roundrobin deviceconfig set --type=iops --iops=1 --device=$i; done
В системе управления СХД все доступные порты Ethernet или FC назначаются таргетами для каждого виртуального логического тома — LUN. Таким образом, каждый LUN после его презентации станет доступен гипервизору по всем путям. Объединение нескольких путей виртуального логического тома в одно устройство хранения на гипервизорах ESXi выполняется с помощью инструмента VMware Native Multipathing Plug-In.
Принципы и порядок испытаний
Наш приоритет — создание аналогичных условий и применение одинаковых программных и аппаратных средств для всех СХД, которые проходят у нас испытания. Так удобнее сравнивать производительность и другие параметры различных моделей.
Перед началом испытаний мы всегда согласовываем с производителем СХД версию прошивки микрокода и, если необходимо, обновляем прошивку до рекомендованной.
Важное замечание:
В ходе испытаний не предполагается замена микрокода и аппаратных компонентов, за исключением тех случаев, когда они вышли из строя;
Если устранить проблемы можно только установкой новой версии микрокода, мы начинаем испытания заново, так как замена управляющего ПО может повлиять на производительность и поведение СХД в разных ситуациях. Вместе все это приведет к нерелевантности результатов испытаний.
Производитель во время испытаний для нас — одновременно и консультант, и специалист техподдержки: он отвечает на вопросы и способствует оперативному решению проблем. Производитель получает развернутую обратную связь в процессе испытаний и знакомится с достигнутыми результатами. Однако все работы на каждом этапе испытаний выполняем исключительно мы сами. И да, мы открыто говорим: либо производитель, либо дистрибьютор тоже подвергается испытаниям, т.к. в ходе работ мы фиксируем и оперативность, и уровень качества их техподдержки.
Испытания можно разделить на несколько этапов:
Проверка документации;
Функциональные испытания;
Нагрузочные испытания;
Испытания по отказоустойчивости.
Остановимся подробно на каждом из них.
Проверка документации
Полнота документации влияет на качество дальнейшего процесса эксплуатации СХД в продуктивной среде. Вот почему в процессе испытаний мы проверяем и отмечаем все найденные несоответствия документации практическому применению СХД и ошибочные сведения. Наши главные требования к документации — наличие разделов:
Руководство по проектированию и внедрению (Design Guide, Planning Guide);
Руководство по установке (Installation Guide);
Руководство администратора (Admin Guide);
Руководство по устранению неполадок (Troubleshooting Guide);
Руководство по обслуживанию (Maintenance Guide) — опционально;
Руководство по производительности (Performance Guide) — опционально;
Руководство по мониторингу (Monitoring Guide) — опционально;
Документация по API — опционально;
Документация по CLI — опционально.
Отсутствие любого раздела или ошибки в нем могут стать тем самым критическим фактором, из-за которого мы поставим под сомнение целесообразность продолжать испытания или сразу приостановим их до устранения замечаний.
Функциональные испытания
Мы проводим их для того, чтобы оценить методы управления и проверить соответствие практических функциональных возможностей СХД тем, которые заявляет производитель, а также испытать те, которые нужны нам. После получения заполненного опросника мы составляем список того, что планируем проверить. Затем собираем подробную информацию из документации по СХД, а недостающие данные уточняем у технических специалистов производителя.
Перед началом функциональных испытаний на СХД подается фоновая нагрузка примерно в 75% от максимальной производительности, установленной в ходе нагрузочного тестирования.
Ниже приводим список большинства функциональных возможностей, которые мы обычно проверяем. Некоторые — опциональны и зависят от потенциальных сценариев применения СХД.
Управление СХД через графический интерфейс (GUI)
Управление СХД через интерфейс командной строки (CLI)
Управление СХД через прикладной программный интерфейс (API)
Обновление программного обеспечения (микрокода) во время работы СХД
Мониторинг СХД
Создание толстых томов (thick provisioning)
Создание тонких томов (thin provisioning)
Регистрация портов инициаторов в качестве серверов
Изменение портов инициаторов в серверах
Поддержка Host Group
Поддержка LUN Group
Настройка Host LUN
Отображение WWID логических томов
Переименование объектов
Клонирование томов
Мгновенные снимки (snapshots)
Миграция логических томов между пулами (volume migration)
Миграция логических томов между контроллерами (volume migration) для ALUA
Компрессия (compression)
Дедупликация (deduplication)
Функциональность QoS (Quality of Service)
Наличие у СХД API для получения метрик производительности
Функциональность внешнего мониторинга
Замена и добавление компонентов в СХД
Поддержка доступа к данным через протокол и сети FC
Поддержка доступа к данным через протокол iSCSI и сети ETHERNET
Поддержка доступа к данным через протокол NVME и сети FC
Поддержка доступа к данным через протокол NVME и сети Ethernet-RoCE
Поддержка доступа к данным через SAS-подключение
Поддержка файловых протоколов CIFS, NFS
Проверка статуса логина
Совместимость с ПО многопутевого доступа Linux, VMWare
Функциональность агрегации портов Ethernet
Функциональность тегирования трафика
Ролевая модель доступа к управлению
Функция доменной аутентификации и авторизации, ролевой доступ для управления СХД
Функция доменной аутентификации и авторизации для доступа к данным через файловые протоколы доступа
Разделение ресурсов по зонам/виртуальным СХД
Возможность создавать дисковые пулы
Функция Tirieng
Функциональность расширения виртуальных (логических) томов
Функциональность синхронной репликации данных на другую СХД
Функциональность асинхронной репликации данных на другую СХД
Интеграция с органами управления виртуализации
Полноценная работа без использования каких-либо внешних облачных сервисов и услуг
Нагрузочные испытания
Они необходимы для определения производительности СХД в заданной конфигурации и в штатном режиме работы под различными типами рабочей нагрузки. Количество путей на СХД и их суммарная пропускная способность должны быть достаточными для 100%-й утилизации системы хранения, чтобы оценить ее предельную производительность.
Производительность СХД мы оцениваем по следующим параметрам:
OPS — количество операций ввода-вывода в секунду;
Throughput — пропускная способность;
Latency — задержка.
Нагрузка на систему хранения во время испытаний максимально приближена к условиям эксплуатации: заполненность СХД данными составляет 90% от общедоступного полезного дискового пространства.
При использовании в СХД SSD/NVMe-накопителей необходимо учесть особенности твердотельных устройств. Для них, с учетом строения памяти NAND, случай перезаписи наиболее трудоемок. Это требует предварительной подготовки до нагрузочных испытаний, когда мы хотя бы один раз заполняем случайными данными и перезаписываем на 100% весь полезный объем СХД. Затем мы заполняем (размечаем) 90% (или другой предварительно согласованный объем) полезного пространства и проводим на нем испытания. Это нужно для того, чтобы СХД функционировала с такой областью как с активной, а не использовала неразмеченное и ранее неиспользуемое пространство на SSD/NVMe-накопителях для повышения производительности. Нам нужно избежать эффекта «нового накопителя», при котором СХД с новыми твердотельными накопителями демонстрируют значительно более высокую скорость работы по сравнению с реальными условиями длительной эксплуатации.
В процессе проведения нагрузочных испытаний запрещается менять настройки СХД и тестового стенда, поскольку в противном случае результаты следует интерпретировать как полученные на различных конфигурациях испытательного стенда. Изменения допустимы только при наличии обоснованных предпосылок, что производительность СХД повысится после настройки.
Как мы уже упоминали, мы запускаем нагрузку на презентованные с СХД виртуальные логические тома с помощью программного генератора синтетической нагрузки VDBench. В нем мы задаем размер блока данных, параметры соотношения чтения и записи операций ввода-вывода, процент диапазона адресов случайного доступа, параметр ограничения области на операции ввода-вывода. Полную информацию о параметрах программного генератора синтетической нагрузки VDBench можно получить из документации производителя.
Испытания нагрузочными профилями выполняем с логическим разделением каждого презентованного LUN на горячие и холодные зоны.
Под горячей зоной мы подразумеваем область ресурса хранения, которая подвергалась нагрузке — прогреву соответствующим профилем в течение 20 часов. Такой прогрев позволяет гарантированно переполнить кэш СХД, чтобы, по сути, вывести его на предельный режим работы и таким образом определить «чистую» производительность системы хранения данных, которую мы испытываем. Это действие производится с целью попадания в кэш СХД максимального количества данных с этой зоны, так как к ней могут предъявляться повышенные требования по производительности. Мы называем это «пробить кэш». Сразу же после окончания этапа прогрева начинается этап продуктивной нагрузки на эту зону этим же профилем для фиксации данных производительности IOPS и задержки операций ввода-вывода.
Холодная зона. Здесь мы подразумеваем область ресурса хранения, которая не подвергалась нагрузке до начала испытаний. Важно, что данные из этой области не должны пребывать в кэше СХД, так как нагрузка подавалась только на горячую зону. Тестирование холодной зоны начинается сразу после испытания горячей и должно быть завершено в течение 4-5 часов после начала нагрузки на холодную зону. В противном случае произойдет окончательное «размытие» зон, которое повлияет на релевантность результатов. Если зафиксировать нужные результаты не получилось, возвращаемся на этап прогрева и начинаем испытания этим профилем нагрузки заново.
По завершении нагрузочных испытаний мы контролируем их повторяемость, измеряя и сравнивая данные при повторной нагрузке с использованием любого из профилей. Если разница между исходным результатом и результатом повторного измерения превышает 10%, мы проводим проверку стабильности работы СХД при длительной нагрузке. Такая проверка может потребоваться и в том случае, если нам кажется, что СХД отрабатывает нестабильно: например, мы фиксируем деградацию производительности, которая мешает воспроизведению полученных результатов, или непредсказуемые отказы СХД в процессе испытаний, которые сложно связать с конкретными действиями. Это позволяет выявить возможные неисправности как аппаратной, так и программной частей СХД.
Современные промышленные СХД, в основном, оснащены функциями дедупликации и компрессии данных. В статье мы остановились на нагрузочных испытаниях СХД без проверки этих функциональных возможностей. Но в реальности мы проводим испытания в том числе в этих режимах и даем реальную оценку достигнутых коэффициентов дедупликации и компрессии.
Испытания по отказоустойчивости
Эти испытания позволяют проверить степень устойчивости СХД в случае отказа какого-либо компонента и понаблюдать за поведением системы во время подобной чрезвычайной ситуации. Главная цель — измерить возможное снижение производительности и зафиксировать прерывание операций ввода-вывода во время отработки отказа и возврата к изначальному состоянию. Мы также испытываем СХД на устойчивость к работе при заполнении более 90% ее полезного пространства.
Все этапы испытаний по отказоустойчивости СХД согласовываются с производителем заранее. Их набор может различаться и зависит от архитектуры СХД, а также от согласования с производителем возможности проведения тех или иных «деструктивных» действий в том случае, если СХД — собственность производителя и предоставлена нам для испытаний.
Перед началом каждого этапа испытаний по отказоустойчивости на СХД подается нагрузка в 75% от максимальной производительности, полученной в ходе нагрузочных испытаний определенным профилем. Работа СХД под нагрузкой сохраняется до окончания каждого теста, чтобы мы могли зафиксировать значения производительности на каждом этапе.
Чем мы руководствуемся при проведении испытаний по отказоустойчивости СХД?
Любой этап начинается с проверки и подтверждения, что СХД работает в штатном режиме: в системе должна отсутствовать индикация о сбое какого-либо аппаратного или программного компонента.
Любой этап считается успешно завершенным, если работа СХД после него восстанавливается до штатного состояния, а уровень производительности возвращается к исходным значениям с отклонением не более 10%. Время, необходимое для восстановления первоначальной производительности под нагрузкой, определяется документацией на СХД или рекомендациями производителя, и в стандартном случае не должно превышать 48 часов. Если в ходе испытаний возникает необходимость полностью отключить нагрузку на СХД для ее возврата в штатное состояние, результат считается неуспешным.
Для каждого этапа мы фиксируем показатели производительности (IOPS, throughput, latency) как в момент отказа какого-либо компонента, так и в процессе его восстановления. Эти показатели производительности мы представляем в отчете в виде графиков с четким временным указанием на важные события, происходящие в процессе испытания. Дополнительно мы указываем среднюю производительность до начала, во время и после завершения этапа испытания.
Ожидается, что все системные события в ходе этапов испытаний отображаются в графическом интерфейсе и доступны через командную строку консоли СХД, не говоря о внешней системе мониторинга. Каждое системное событие должно быть зафиксировано в журнале событий СХД с полным описанием и точным временем его возникновения. Также на передней панели СХД у нас предусмотрена индикация, информирующая о режимах работы (аварийном или штатном) в зависимости от наличия или отсутствия соответствующих событий.
Допустимый уровень снижения средней производительности в IOPS за определенный период времени не может составлять более чем 50% по сравнению с показателями, зафиксированными до начала данного этапа. Прерывания операций ввода-вывода разрешены исключительно на тех этапах испытаний по отказоустойчивости, где это ожидается, и их продолжительность не должна превышать требуемый нами уровень. В противном случае мы расцениваем зафиксированные остановки ввода-вывода как неуспешный результат этапа испытания.
Подробно описываем в отчете все полученные результаты и отработку СХД во время каждого этапа испытаний по отказоустойчивости.
В таблице ниже представлен перечень некоторых этапов испытаний по отказоустойчивости СХД в нашей лаборатории. В колонке «Этап испытаний» указано название каждого этапа, в колонке «Цель» сформулирована цель, которую мы ставим на данном этапе испытаний, а в колонке «Ожидаемый результат» приведены описания удовлетворительных результатов для каждого из этапов.
№ | Этап испытания | Цель | Ожидаемый результат |
1 | Обесточивание и извлечение одного БП на контроллерной шасси. | Проверка работы СХД при отказе одного луча питания на контроллерном шасси. | Основные критерии: • отсутствие сбоев в работе СХД; • отсутствие прерываний операций ввода-вывода.
Вторичные критерии: • запись сообщений о потерях электропитания и извлечении блока питания в системном журнале СХД; • наличие активных уведомлений о работе в аварийном режиме на главной панели управления в графическом интерфейсе СХД; • активная индикация на панели корпуса СХД, сигнализирующая о работе в аварийном режиме. |
1.2 | Обесточивание и извлечение одного БП на дисковой полке расширения. | Проверка работы СХД при отказе одного луча питания на дисковой полке расширения. | |
1.3 | Одновременное обесточивание по одному БП на контроллерной шасси и на дисковой полке расширения. | Проверка работы СХД при отказе одного луча питания на контроллерной шасси и на дисковой полке расширения. | |
2 | Имитация отказа одного контроллера.
| Проверка работы СХД при отказе одного контроллера. Проверка перестроения карты Multipath I/O доступа для инициаторов. | Основные критерии: • допускаются прерывания операций ввода-вывода, в рамках предусмотренных в общем положении проведения испытаний по отказоустойчивости; • восстановление работы отключенного или извлеченного контроллера осуществляется без остановок и деградации операций ввода-вывода; • отсутствует необходимость отключения нагрузки для восстановления штатного режима работы СХД.
Вторичные критерии: • управление СХД доступно через SSH и веб-интерфейс; • регистрация соответствующих сообщений в системном журнале событий с указанием временных меток; • наличие активных уведомлений о работе в аварийном режиме на главной панели управления графического интерфейса СХД; • активная индикация на панели корпуса СХД, сигнализирующая о работе в аварийном режиме. |
3 | Поочередное выключение – включение, перезагрузка, перевод в режим обслуживания контроллеров (при наличии). | Проверка работы СХД на типовые действия с контроллерами применимые в рамках сервисных работ (обновление микрокода, замена контроллера). | |
4 | Имитация частичного и полного отказа интерконнекта между контроллерами. | Проверка работы СХД при потере интерконнекта между контроллерами. | |
5 | Имитация отказа одного накопителя под нагрузкой. | Проверка работы СХД при выходе из строя одного накопителя. Мониторинг процедуры восстановления массива и утилизации вычислительных мощностей СХД.
| Основные критерии: • автоматический запуск восстановления массива (при использовании соответствующего уровня метода защиты – RAID) с применением резервного накопителя, если таковой имеется; • отсутствие прерываний операций ввода-вывода; · допустимо снижение производительности пропорционально количеству извлеченных накопителей, использующихся для построения пула данных.
Вторичные критерии: • наличие соответствующих уведомлений на главной панели управления в графическом интерфейсе СХД; • регистрация соответствующих сообщений в системном журнале событий с указанием временных меток; • активная индикация на панели корпуса СХД, сигнализирующая об отказе накопителей.
|
6 | Имитация отказа двух накопителей под нагрузкой. | Проверка работы СХД при выходе из строя двух накопителей. Мониторинг процедуры восстановления массива и утилизации вычислительных мощностей СХД.
| |
7 | Возврат накопителей под нагрузкой. | Мониторинг за восстановлением массива. | Основные критерии: · отсутствие прерываний операций ввода-вывода; · успешное завершение восстановления массива без потери данных под нагрузкой; · восстановление производительности до прежних показателей – до момента имитации отказа накопителя. Вторичные критерии: · регистрация соответствующих сообщений в системном журнале событий с указанием временных меток; · индикация на панели корпуса, сигнализирующая о штатной работе СХД. |
8 | Имитация отказа портов ввода-вывода на уровне одного трансивера, одной сетевой карты, одного коммутатора. | Проверка отказоустойчивости и производительности СХД при сбоях на уровне многопутевого ввода-вывода — Multipath I/O. | Основные критерии: · допускается снижение производительности пропорциональное количеству отключенных портов; · допускаются прерывания операций ввода-вывода, в рамках предусмотренных в общем положении проведения испытаний по отказоустойчивости; · восстановление производительности до прежних показателей при возобновлении доступа по ранее отключенным путям. Вторичные критерии: · управление СХД доступно через SSH и веб-интерфейс; · регистрация соответствующих сообщений в системном журнале событий с указанием временных меток; · наличие активных уведомлений на главной панели управления графического интерфейса СХД о соответствующих сбоях; · активная индикация на панели корпуса СХД, сигнализирующая о сбоях.
|
9 | Имитация частичной потери соединения дисковой полки расширения с контроллерной шасси на уровне одного SAS порта. | Проверка работы СХД при частичной потере соединения дисковой полки расширения с контроллерной шасси на уровне одного SAS/PCIe соединений путем извлечения miniSAS кабеля. | Основные критерии: · отсутствие прерываний операций ввода-вывода; · отсутствие остановок операций ввода-вывода при возобновлении SAS/PCIe соединений; · отсутствие необходимости отключения нагрузки на СХД для восстановления штатного режима работы.
Вторичные критерии: · управление СХД доступно через SSH и веб-интерфейс; · регистрация соответствующих сообщений в системном журнале событий с указанием временных меток · наличие активных уведомлений на главной панели управления графического интерфейса СХД о соответствующих сбоях; · отображение соответствующих сообщений в логах с временной отметкой; · сигнализация об отказе с помощью внешней индикации на корпусе контроллерного блока. |
10 | Имитация потери соединения дисковой полки расширения с контроллерным шасси на уровне одного SAS HBA адаптера. | Проверка работы СХД при отказе одного SAS HBA адаптера, одновременное отключения всех SAS/PCIe соединений путем извлечения miniSAS кабеля. | |
11 | Заполнении полезного пространства данными на 95%, 100%. | Проверка стабильности работы СХД при заполнении полезного пространства данными более 90% с целью оценки деградации производительности. | Основные критерии: · отсутствие прерываний операций ввода-вывода; · отсутствие сбоев в работе СХД. · стабильная производительность
|
Если провести один или несколько этапов испытаний невозможно, или от их проведения отказывается сам производитель СХД, мы оставляем за собой право признать СХД непригодной к эксплуатации.
Порой в ходе испытаний обнаруживаются критические недостатки, из-за которых СХД может быть признана непригодной к применению в наших проектах: потеря данных, полная остановка ввода-вывода в результате стандартных операций в процессе сервисного обслуживания. В таком случае СХД получает метку «В "РТК-ЦОД" применять нельзя!» с указанием текущего микрокода. С производителем мы можем обговорить сроки, в которые он обязуется устранить выявленные недостатки, чтобы при необходимости провести повторные испытания.
По окончании всех этапов испытаний мы приступаем к составлению подробного отчета. В нем мы предоставляем проанализированную информацию по всем полученным результатам и графики производительности, полученные для каждого профиля нагрузки на всех этапах испытаний — и нагрузочных, и во время тестов отказоустойчивости. Мы включаем в отчет, в том числе, резюме о клиентском опыте взаимодействия с технической поддержкой разработчика, опыте сотрудничества с производителем, а также рекомендации по эксплуатации СХД с учетом выявленных особенностей ее работы.
На основе собранных данных и критериев успешности мы делаем выводы о целесообразности использования испытуемой СХД в проектах «РТК-ЦОД».
А напоследок, пользуясь случаем, хотим поблагодарить за помощь и участие в развитии нашего направления и в разработке ПМИ коллегу — Алексея Егорова, специалиста высочайшего уровня в области СХД, который с живым интересом и профессионализмом ежедневно развивает это направление.
