Схд huawei oceanstor 5110 v5 настройка
Обновлено: 07.07.2024
Видеонаблюдение - одна из основных движущих сил на рынке систем хранения данных. Снижение стоимости IP-камер привело к тому, что сегодня их устанавливают сотнями, зачастую рядом друг с другом, направленные в одну точку, но с разным фокусным расстоянием, чтобы снимать общий план и захватывать лица, использовать интеллектуальный анализ кадра и просмотр с разных ракурсов. В ближайшем будущем нас ждёт распространение технологий на основе Big Data, где система наблюдения станет основным поставщиком данных для анализа поведения покупателей в магазинах, пассажиров на вокзалах и сотрудников бизнес-центров. Простой принцип «записал и сохранил» уже сегодня дополняется словом «проанализировал», поэтому сердцем систем видеонаблюдения становится не просто большая полка с дисками, куда всё записывается, а мощный вычислительный узел, способный работать с этими записями.
OceanStor 2800 V3 - это двухконтроллерная система хранения, построенная по схеме Active-Active без единой точки отказа. В основе каждого контроллера стоит 6-ядерный процессор Intel Xeon E5 2620v2 с 48 Гб оперативной памяти, используемой для гостевых операционных систем и кэширования записи. Для виртуализации основной плюс двухконтроллерного решения - это встроенный механизм Failover, благодаря которому вы получаете два вычислительных узла с двойной защитой: если один контроллер зависнет или выйдет из строя, в течение нескольких минут виртуальная машина запустится на втором контроллере и видеонаблюдение продолжит работать.
Первоначальная настройка
Сразу хочется сказать, что несмотря на очень качественный Web-интерфейс, в настройке Huawei OceanStor 2800 сложна: всё, что касается виртуализации устанавливается через командную строку с использованием SSH подключения. Сам гипервизор (используется разработка компании Red Hat) - не основная функция СХД, поэтому даже для создания виртуалок придётся использовать все возможные средства: и терминал, и web-интерфейс, и даже SFTP-клиент для загрузки образа установщика, благо в системах видеонаблюдения это делается один раз. Начинаем с того, что инициализируем СХД и настраиваем дисковые пулы.
Huawei OceanStor 2800 выпускается только в варианте 2U под 3.5-дюймовые жёсткие диски, что в общем-то, вполне логично для системы видеонаблюдения. По умолчанию 4 отсека уже заняты системными жёсткими дисками (600GB, 10K RPM, SAS, HGST body), которые объединены в единый RAID 1 пул для программного обеспечения СХД и не участвуют в общем дисковом пространстве для хранения данных.
Как и все системы хранения данных Huawei, модель OceanStor 2800 имеет аппаратную привязку к жёстким дискам того же производителя. Как правило, Huawei использует накопители HGST, и для видеонаблюдения вам доступны только SATA-накопители, в нашем случае - серии He10, снабжённые переходником на SAS, необходимым для подключения к двум контроллерам. Для крупных проектов производитель предлагает использовать 8 системных жёстких дисков с интерфейсом SAS вместо четырёх. Но мне трудно сказать, насколько обоснован этот шаг, ведь на этих дисках хранится софт, который после запуска практически не использует системнй диск, а весь архив пишется на отдельный пул, который мы сейчас и настроим.
Мы объединяем 4 SATA диска в аналог RAID 5, который благодаря блочной виртуализации (технология Huawei RAID 2.0+), может выдерживать поломку 4 и более винчестеров, после чего создаём LUN-ы для привязки к виртуальным машинам. Именно они будут использоваться для архива видеонаблюдения, а связь между LUN-ами и виртуальными машинами будет осуществляться по виртуальной шине vHBA, так что высокоскоростные Front-end интерфейсы для хранения видеозаписей нам не нужны, и не важно, на каком контроллере работает виртуалка - диск E: под Windows всегда будет доступен.
Из терминала создаём виртуальную машину и выделяем ей аппаратные ресурсы. Здесь надо иметь в виду, что динамическое распределение памяти в гипервизоре отсутствует, так что для отказоустойчивости нужно рассчитать, чтобы суммарный объем всех виртуалок (основных и работающих в режиме отказоустойчивости) не превышал объем доступной памяти на одном контроллере. Всего поддерживается создание до 3 виртуальных машин на контроллер, и мы выделим 8 Гб ОЗУ для тестовой машины. По sFTP подключимся к контроллеру и загрузим на него .iso образ тестовой Windows 7, смонтируем его и запустим инсталляцию. После установки Windows, нам нужно обязательно проинсталлировать пакет VMTools, чтобы указать операционной системе использование дискового драйвера VirtIO, что даст возможность настроить отказоустойчивость. Как только этот шаг пройден, опять же из терминала указываем нашей виртуальной машине работу в режиме Failover. Всё, осталось только протестировать переброс виртуалки между контроллерами при отработке отказа.
Отказоустойчивость виртуальных машин и защита по питанию
Проверим схему работы отказоустойчивого кластера, созданного на базе одной-единственной СХД. Для этого на запущенной Windows 7 создаём текстовый файл, сохраняем в него метку текущего времени и на горячую отключаем контроллер, на котором работает виртуалка.
Увидев, что связь с вычислительным узлом пропала, Huawei OceanStor 2800 запускает виртуалку с резервного контроллера, и уже через пару минут мы наблюдаем наш рабочий стол с сохраненной временной меткой. Надо иметь в виду, что живой миграции машин между вычислительными узлами нет, поэтому как только мы подключаем основной контроллер обратно, наша Windows 7 будет заново перезапущена на своём контроллере. Таким образом, гипервизоры функционируют в режиме Active-Passive с постоянно сохраняющейся ролью главного и резервного, а downtime-период гостевой операционной системы при переключении вычислительного узла составляет 1 минуту 26 секунд.
Защита памяти от внезапного отключения электричества возлагается на массивные литий-ионные аккумуляторы ёмкостью как у современных ноутбуков - 4300 мАч. Два аккумулятора располагаются в модулях блоков питания и могут быть заменены на горячую, без остановки СХД. Использование таких больших батарей связано с тем, что для записи данных памяти на резервный MSATA-диск объемом 64 Гб нужно поддерживать работу всех систем СХД: чипсета, процессора и кулеров. Электрически аккумуляторы не связаны напрямую с блоком питания - только через общую плату. Так что если правый блок питания сломался и отключился, батарею может заряжать левый. Аккумуляторы постоянно находятся под потоком воздуха от 16-скоростных вентиляторов, так что перегрев им не страшен, но для большей уверенности производитель заключил батареи в стальные корпуса, всё же литий-ионные АКБ из-за деятельности Samsung и Apple имеют печальную славу пожароопасных, так что с мощным охлаждением и в стальной коробке за них как-то спокойнее.
Давайте протестируем как поведёт себя виртуальная машина при отключении питания - откроем Notepad и пропишем в нём текущее время, не сохраняя файл на диск, после чего обесточим систему хранения данных.
После возобновления питания Huawei OceanStor 2800 автоматически запускает виртуалку, но перед нами - пустой рабочий стол: снимок памяти не сохранился. То есть, если контроллеры СХД работают в режиме Active-Active, то для виртуальной машины применяется схема Active-Passive. В среднем, время запуска Windows 7 составляет около 40 секунд при настройках 16 vCPU / 16 Gb RAM и запуске с системных жестких дисков. Это довольно-таки быстро, так что давайте посмотрим, на каком железе работает гипервизор OceanStor 2800V3.
Контроллеры
Каждый контроллер имеет по одному процессору Intel Xeon E5-2620 v2, уже устаревший по современным меркам. Если производительность CPU имеет для вас решающее значение, посмотрите на более новую OceanStor 2800 V5, хотя как мы увидим дальше при тестировании, для видеонаблюдения в сотни потоков хватит даже того, что есть. Память набрана шестью модулями DDR3-1600 ECC объемом по 8 Гб каждый, ещё два свободных слота снабжены заглушками, чтобы не создавать свободного коридора для воздушного потока. Контроллеры, как и интерфейсы, могут меняться на горячую без остановки СХД.
Для связи между контроллерами используется шина PCI Express 3.0 (до 8 Гб/с), причем Huawei подчеркивает, что для OceanStor 2800 основным программным слоем является как раз SAN, поэтому загрузка процессоров никак не влияет на скорость передачи данных, а вот это утверждение мы сейчас и проверим!
Тест зависимости скорости SAN от загрузки vCPU
Для каждой виртуальной машины на OceanStor 2800 V3 доступно до 32 vCPU, и мы с вами знаем, что ни одно приложение, ни одна база данных не дадут такой нагрузки на процессор, как Burn-In тест OCCT 4.5.1. Загрузим им из-под Windows 7 все 32 логических ядра и посмотрим как поменяется время доступа к дисковым ресурсам по iSCSI, а для полноты картины продублируем эксперимент с одним отключенным контроллером.
Наши тесты показывают, что время доступа не зависит от загрузки процессора, а значит на аппаратном уровне хранилище и вычислительный узел не связаны, и можно не опасаться, что видеонаблюдение повлияет на обслуживание нужд иных приложений и серверов: вот она, конвергентность в чистом виде.
Отказоустойчивость на уровне портов
По умолчанию, на каждом контроллере уже имеются 4 интерфейса 1Gbps BASET, что в сумме даёт скорость около 1 гигабайта в секунду на СХД, плюс к этому пятый порт управления может использоваться для виртуальной машины (iSCSI соединение через него недоступно). Много это или мало? Если взять китайскую IP-камеру с разрешением 1080p, то обычно с кодеком H.264 она создаёт поток около 5 Мбит/с, и встроенных сетевых портов хватит для подключения 1500 таких камер, то есть больше, чем официально заявлено производителем. Так что именно для нужд видеонаблюдения, дополнительные сетевые интерфейсы могут и вовсе не понадобиться - была бы возможность разделить трафик по портам, и вот здесь нас ждёт небольшая неприятность: в виртуальную машину можно пробросить только те интерфейсы, которые подключены к контроллеру, на котором она работает, то есть нам доступны 4 ETH Front-End порта и пятый порт управления. При расчете в китайских IP-камерах это примерно 900 каналов с разрешением 1080p.
Для iSCSI-доступа таких ограничений нет, и к любому контроллеру можно подключиться через любой из Front-end интерфейсов, так что под VMware vSphere достаточно настроить два соединения к двум IP-адресам контроллеров, и получить отказоустойчивый доступ, и раз уж мы заговорили про iSCSI, то давайте измерим скорость переключения между контроллерами в режиме Active-Active для теста Random 4K Read.
Как мы видим по графику, переключение между контроллерами занимает около 37 секунд, а при восстановлении СХД в нормальный режим Active-Active, обратный переброс дискового пула происходит за 5 секунд, при этом время доступа на основном и резервном контроллерах одинаковы.
- 4 порта RJ45 1G BaseT
- 4 порта RJ45 10G BaseT
- 4 порта SFP+ 10G ETH (адаптеры серии SmartIO)
В нашей статье про сравнение SFP+ и BASE-T мы показали, что задержки при iSCSI доступе между медным и оптическим интерфейсом могут достигать 20% (на флэш-массивах), но применительно к OceanStor 2800 имеет смысл установить дополнительно 4 порта 1G BaseT для видеонаблюдения и 4 порта SFP+ для SAN-сетей.
Настройка софта
Ну вот мы и подошли к финальной части настройке - установке ПО для видеонаблюдения. Как вы уже поняли, какого-либо встроенного программного решения на OceanStor 2800 V3 нет, так что нам доступно всё, что создала наука для Linux или Windows. Среди десятков дистрибутивов разобраться непросто, и друзья, занимающиеся поставками IP-камер Zavvio для интеграторов, посоветовали обратить внимание на Axxon Next и Macroscop. Последний разрабатывается нашими соотечественниками из Перми, этот программный пакет имеет дополнительные модули по анализу изображения, такие как "детектор касок" для строительных объектов, детектор очередей для касс, создание тепловых карт движения покупателей, распознаватель гос. номеров и прочие. Плюс, Macroscop более гибко использует дисковые ресурсы для видеоархива и как-то проще в настройке, поэтому Axxon Next был отложен до лучших времён, и в дело пошёл пермский продукт.
Скачиваем с сайта Macroscop дистрибутив и устанавливаем под виртуальную Windows 7 полный демо-комплект софта для видеонаблюдения (около 1 Гб). В режиме клиент+сервер, отображение на экране тепловых карт и видеопотоков приводят к тому, что загрузка составляет примерно 30-40% процессорного времени для 32 vCPU. Это, конечно, не дело - оставим на СХД только серверную часть видеорегистратора, а клиентскую вынесем на отдельный хост, ведь Macroscop поддерживает ускорение вывода на GPU, что нам очень пригодится.
Чтобы настроить отказоустойчивую работу и распределить нагрузку по контроллерам, нам нужна вторая виртуальная машина, которая будет работать на втором контроллере, дабы задействовать оба процессора для нужд для видеонаблюдения. Функции клонирования или миграции в гипервизоре OceanStor 2800 V3 не имеется, так что конвертируем виртуалку в шаблон, выполняя простую команду из терминала, а затем воссоздаём новую виртуалку на основе сохраненного образа, таким образом мы сократим время инсталляции с нескольких часов до нескольких минут.
После запуска двух Windows 7 убеждаемся, что Macroscop запущен на обоих контроллерах, идём в настройки программы и устанавливаем второй сервер. Клиентскую часть я вынес на Windows 10 x64, запущенную под VMware Workstation 14.1.3 из десктопного компьютера, чтобы все три компонента были виртуализированы - это облегчит бэкап и резервное восстановление в случае аварии. Да, привыкаем к тому, что держать профессиональное приложение на физическом хосте можно только в самом крайнем случае.
Тест 400 HD-потоков
Для того, чтобы протестировать возможность работы Huawei OceanStor 2800 V3 с видеопотоками, мы будем использовать эмулятор IP-камер, запущенный на тестовом стенде, который можно скачать с сайта разработчика софта вместе с дистрибутивом ПО. Здесь нужно сделать одну ремарку: эмулятор работает в 1-канальном режиме, а многоканальность настраивается клонированием камеры в сервере Macroscop. При этом, каждый канал по одному и тому же IP-адресу запрашивает видеопоток с эмулятора, так что мы получаем нагрузку и на сеть, и на дисковую подсистему СХД, всё как в боевых условиях. На Huawei OceanStor 2800 V3 под виртуалку было выделено 16 vCPU, и там запускалась только серверная часть программного обеспечения, поскольку клиентская очень не оптимизирована - ей для нормальной работы требует ускорение через GPU и запустив её на игровом компьютере, я задумался об очередном апгрейде.
На сегодняшний день на рынке дисковых массивов от компании Hauwei существует легкая неразбериха. Связано это с тем, что за неполный год Huawei анонсировал целых 2 новых поколения СХД, оставляя при этом на рынке ряд решений из предыдущих линеек. При этом разница между поколениями достаточно значима.
Поэтому, я решил рассказать о текущих предложениях компании Huawei для прояснения данного вопроса.
Итак, сейчас на рынке представлено 3 разных поколения систем хранения данных Huawei OceanStor.
От первого поколения остался бюджетный массив Entry уровня OceanStor S2200T V1.
Второе поколение представлено Low-end массивом OceanStor S2600T V2.
А Mid-range начинается с третьего поколения — обновленная линейка OceanStor 5300 V3 и выше.
Обособленно стоит High-end линейка 18000, которая пока не получила обновление в третьем поколении. Однако младший из High-end'ов OceanStor 18500 V2 оказался равен новому пограничному mid-range массиву OceanStor 6800 V3, что постепенно вытеснит его из модельного ряда Huawei.
Давайте разберемся с чего все начиналось, и к чему же все пришло.
Первое поколение
Первое поколение OceanStor представляло собой достаточно сбалансированную линейку блочных массивов с слабоватой функциональной составляющей:
Модели S2600T V1, S5500T V1, S5600T V1 и S5800T V1 являлись унифицированными, т.е. имелась возможность сконфигурировать их с файловым доступом. Осуществлялось это по самой распространенной схеме — с использованием отдельной файловой головы (File Engine). Файловая голова представляла собой отказоустойчивую связку из дублированных серверов общей высотой в 4U.
Такой подход к построению унифицированных массивов выигрывал с точки зрения производительности по сравнению с «честным юнифайд» (например EMC VNXe3200, NetApp) за счет масштабируемости, однако, проигрывал с точки зрения бюджетирования и банальной экономии стоечного пространства.
С точки зрения функционала, первое поколение отставало от современных ему лидеров рынка — не было многоуровневого тиринга, partition и т.д. Поэтому Hauwei принимает решение обновить модельный ряд, выпустив второе поколение массивов.
Второе поколение
По факту, второе поколение отличается от первого только обновленным микрокодом. Переписав его с нуля, они заметно расширили функционал своих СХД, но, внесли крайне нелогичные ограничения:
Основной фичей второго поколения стал обновленный подход к организации дисковых пространств — технология RAID 2.0+
И пусть вас не смущает название — к уровням RAID эта технология никакого отношения не имеет. По сути это виртуализация дисков системы для организации единого пула. В дальнейшем, этот пул разбивается на чанки, чанк-группы и экстенты, из которых уже собираются классические LUN'ы. Аналогичный подход использует HP в своих системах 3Par и Hitachi в HUS'ах.
Из явных преимуществ такого подхода можно выделить:
• Равномерное распределение нагрузки между физическими носителями.
• Ускорение восстановления данных из контрольных сумм в случае краха носителя.
• Ускорение расширения пулов и пересборки RAID-групп в случае добавления в систему новых носителей.
• Изменение типа раздела (многоуровневый\одноуровневый) «на лету»
Из добавленного функционала можно выделить:
• SmartPartition — выделение изолированных кусков кэш-памяти для выбранных разделов.
• SmartTier — многоуровневое хранение данных. Автоматическая «вертикальная» миграция данных между дисками разных уровней (7.2k, 10/15k, SSD) на основании статистики частоты обращения к ним.
• SmartMotion — «горизонтальная» миграция данных между физическими носителями и балансировка нагрузки. По факту, без этой лицензии все вышеописанные преимущества технологии RAID 2.0+ будут недоступны.
• SmartQoS — Quality of Service. Выставление приоритетов вашим разделам на основе критичности размещаемых приложений. В зависимости от выставленного приоритета, система будет гарантировать выделение этому разделу кэш-памяти или, наоборот, ограничивать потребление памяти этим разделом.
• SmartVirtualization — виртуализация массивов сторонних вендоров согласно списку совместимости.
Добавление этого функционала повысило нагрузку на вычислительные ресурсы, которые остались прежними с первого поколения. Поэтому, Entry-массив OceanStor S2200T V1 остался в первом поколении, так как физически не потянул обновленный микрокод, а массив S2600T V2 теперь доступен для заказа только в конфигурации с 16 Gb кэш-памяти.
Однако Huawei решили не бросать S2200T V1 агонизировать. Вместо этого, они обновили конструктив, добавив к уже имеющейся конфигурации контроллеров 12*3.5" с 12*1 GE iSCSI портами возможность заказать конфигурацию 24*2.5" с 8*8 Gbit/s FC. Возможность заказать контроллер с предустановленными FC портами вернула это решение на рынок, сделав его конкурентоспособным за счет низкой стоимости.
Обратной стороной медали стало удаление функционала SmartCache (расширение кэш-памяти за счет SSD-накопителей) и отказ от использования дисков SFF 2,5" в массиве OceanStor S2600T V2. Разумных причин этому я не нашел.
Использование «старого» железа и отсутствие возможности расширения кэша — было явным недостатком массивов Huawei. А, отсутствие 2,5" дисков в массиве S2600T вообще выкинуло его с рынка.
Поэтому, в декабре 2014 Huawei анонсирует новое третье поколение своих унифицированных систем хранения данных OceanStor V3.
Третье поколение
Третье поколение — это глобальное обновление всего модельного ряда. Помимо нового железа и функционала, в Huawei решили изменить подход к организации унифицированного доступа. Они отказались от отдельных файловых нод, организуя файловый доступ за счет ресурсов блочного контроллера.
Помимо этого глобального изменения, обновился и функционал:
• Дедупликация, реализованная на базе ASIC'ов.
• Функция SmartErase («аннигиляция» записанных данных) для соблюдения процедур и регламентов по безопасности.
• Функция SmartMigration — одноразовая миграция всех данных с legacy-массива на вновь приобретенный массив Huawei.
Изменилась и модель лицензирования: функционал SmartThin, SmartMulti-tenant, SmartMigration, SmartErase включили в базу (приобретается вместе с массивом).
При лицензионном апгрейде до унифицированного решения к базовому функционалу добавятся файловые дедуп и компрессия.
Появились софтовые бандлы:
• Data Protection Software suit: включает в себя HyperSnap, HyperCopy, HyperClone, HyperMirror.
• Storage efficieny Software suit: включает в себя SmartCache и SmartTier.
При покупке бандлов заявлена экономия порядка 30% по сравнению со «штучным» приобретением лицензий.
С обновлением железа изменились вычислительные мощности моделей, поэтому, и позиционирование на рынке было несколько изменено.
Так, например, OceanStor 6800 V3 стал полноценный High-end'ом, сменив OceanStor 18500 V2.
Как уже было сказано, в третьем поколении появится дедупликация и компрессия. Реализованы они будут отдельными модулями-ASIC'ми, которые возьмут на себя нагрузку по вычислению fingerprint'ов. Однако хранениться мета-данные все равно будут в кэш-памяти контроллера, так что при активации большого кол-ва функционала тонким местом будет являться объем кэша.
Обновления коснулись и портов ввода/вывода. Появились интерфейсы 16Gbit/s FC, 10 Gbit/s iWARP (scale-out LAN), а так-же back-end 12 Gbit/S SAS.
И, в очередной раз, Huawei не прислушались к рынку и не выпустил 2U полку под диски 3,5", отсутствие которой является ощутимо слабым местом всего семейства OceanStor. Существующая на текущий момент полка 24*3,5" 4U имеет просто ужасную плотность размещения (необходимо разместить 5 дисков 3,5" — покупайте 4U полку). Это особенно удивляет на фоне релиза полки высокой плотности: High-density 75*3.5" 4U.
В связи с этим, Huawei оставил доступным для заказа второе поколение OceanStor V2, чтобы не ограничивать своих клиентов в использовании унифицированных решений. Однако, дата снятия с продаж V2 — декабрь 2015 года.
Весь нереализованный, но заявленный функционал, Huawei обещают зарелизить постепенно к концу этого года. И, как дополнение — заявлен перевыпуск S2200T V1 и S2600T V2 на базе третьего поколения. Что они из себя будут представлять — пока не ясно.
Конспект вебинаров 2, 3, 20 HonorCup E=DC2 для сдачи HCNA Storage.
-
в целом про технологии СХД про эмулятор СХД Huawei
OceAnStor OS
Есть базовый функционал (Basic function control software) и есть функционал дополнительный (Value-added function control software), который докупается в виде лицензионных ключей. В ПО СХД ОС заложено много инструментов по backup/monitoring/восстановлению данных на ЖД (ЖД самый частый сбойный компонент СХД т.к. это элемент с механической компонентой).
Архитектура OceanStor OS
Технологии
Тут описаны технологии, которые не рассмотрены в RAID-контроллерах
Cache mirroring
Cache mirroring используется при наличии нескольких контроллеров в СХД (у Huawei всегда несколько контроллеров, минимум 2). Данные между контроллерами по шине синхронизации синхронизируются для целостности данных в случае отказа одного из контроллеров. Cache mirroring делается всех типов операций – read/write/mirror. Причем главным считается write.
Multipathing
Data coffer
На случай полного фатала с питанием (выход из строя двух БП/обоих лучей питания) в controller enclosure встроен функционал сохранения данных RAID кэша. Реализуется не через BBU+ОЗУ или суперконденсаторы+flash, как на RAID-контроллерах серверов (и на старших моделях СХД), а используя батареи (батарейные блоки BBU) + служебное пространство 4 дисков.
LUN copy
Копирование LUN. Требует запрет на запись (не на чтение) в данный LUN для корректного снятия копии в определенный момент времени.
HyperClone (LUN clone) и Synchronization
Мгновенное копирование LUN используя синхронизацию (synchronization) между LUN. Не требует запрета на чтение, но занимает весь объем, отведенный под LUN, а не только объем данных LUN.
Синхронизация может происходить как между основным и резервным LUN, так и обратно. Для восстановление данных используется обратная синхронизация с клонированного LUN на основной (reverse synchronization). После синхронизации происходит обрыв синхронизации (split) и резервный LUN становится доступным для использования. Он имеет все данные основного LUN до split. Во время синхронизации все операции write будут дублироваться на клонированный LUN.
HyperSnap (Snapshot)
Позволяет снять копию системы (определенного LUN) в определенный момент времени. Есть у всех вендоров СХД. У Huawei основан на технологии copy-on-write (еще популярен у вендоров allocated-on-write).
- Для снятия snapshot не требуется остановка системы, в отличии от LUN copy.
- Snapshot занимает только пространство отведенное под ненулевые данные LUN, а не весь объем, отведенный под LUN, как это делает Clone.
В СХД типа OceanStor 9000 snapshot может быть сделан за одну секунду без влияния на сервис. Подробнее зачем нужны snapshot/replication см. в статье backup.
Существует два варианта восстановления из snapshot:
HyperReplication (Remote Replication)
Репликация данных с одного СХД на другой. Требует несколько одновременно работающих СХД в отличии от LUN copy/snapshot, которые могут быть сохранены на том же СХД. Репликация может быть синхронная или асинхронная (с задержкой), в зависимости от ширины канала и задержки:
В настройках обычно можно задавать максимальную полосу канала, выделяемую под репликацию. Кроме того реплики могут быть полными или инкрементальными.
Могут быть разные варианты реализации репликации между СХД: один к одному/ко многим или двухсторонние реплики. Подробнее зачем нужны snapshot/replication см. в статье backup.
Квоты
Квоты позволяют сделать ограничение для определенных пользователей по объему выделяемого им пространства. Зачастую поддерживается интеграция с NIS/LDAP/AD (слайд для СХД OceanStor 9000).
WORM
WORM – write once read many. Система блокирует после создания файла его изменение и удаление. Таким образом обеспечивается неизменяемость информации (отчеты сотрудников, правовая или медицинская информация). Через определенный период, заданный админом, файл можно удалить или повторно заблокировать, но изменить нельзя.
QoS
Аналогия QoS в IP-сетях, вместо пакетов используются I/O requests. Можно в системе настраивать приоритетность обработки тех или иных запросов на чтение/запись на определенный LUN. В зависимости от приоритета формируются очереди.
Дедупликация
В СХД может быть реализован функционал глобальной дедупликации данных (защиты от дублирования) путем сравнения файлов или объектов между собой (OceanStor 9000). Подробнее о дедупликации см. в отдельной статье.
HyperThin/SmartThin
SmartTier
У вендоров может быть реализована поддержка разных типов дисков (SSD, SAS, NL-SAS). В результате разные по типу диски могут стоять в одной полке. В случае Huawei технология называется SmartTier и поддерживается на RAID 2.0+ и СХД OceanStor 9000 (тут она InfoTier). Для работы SmarTier на Disk Domain нужно чтобы в нем были диски разных типов (не обязательно три типа, можно и два).
SmartTier на основе технологии dynamic storage tiering (DST) определяет, какие данные более востребованы и переносит их на SSD (high-perfomance tier), менее же востребованные же переносит на HDD (perfomance tier: SAS, capacity tier: NL-SAS). Происходит это в три этапа:
- Анализ входящих/исходящих операций (i/o monitoring)
- Анализ возможностей размещения данных (data placement analysis)
- Перемещение данных (data relocation)
Специфические утилиты восстановления
RAID 2.0+
Принцип создания LUN в технологии RAID 2.0+ (тут на английском основные определения):
Преимущества RAID 2.0+ (помимо описанного выше функционала Huawei СХД, который работает в связке с RAID 2.0+):
* все диски находятся в одном дисковом домене (грубо говоря, одном RAID), а не пачке разных RAID под разные задачи. Нарубление LUN по большому количеству ЖД (вместо выделенных), позволяет параллельно запрашивать данные сразу с большого количества ЖД (вместо выделенных), ускоряя тем самым работу и плавно распределяя нагрузку на все ЖД (не унося в полку одни, приводя в том числе к повышенному их износу, при том что другие ЖД мало нагружены).
Подключение к консоли коммутатора
Т.к. в моем ультрабуке нет ни Ethernet порта, ни тем более COM порта я использовал свой адаптер QinHeng Electronics HL-340 USB-Serial adapter (Device 005: ID 1a86:7523). Радует он меня тем, что при подключении по USB сразу даёт вирутуальный COM-порт и не требует никаких драйверов ни под Windows, ни под Linux.
Для подключения использую gtkterm
Configuration -> Port:
Port: /dev/ttyUSB0
Baud rate: 9600
Parity: none
Bits: 8
Stop bits: 1
Flow control: none
После первого подключения возника проблема с тем, что оооочен сильно тормозила консоль. Потом выяснилось, что всемы виной консольный COM -> RJ45 кабель. Заменили его на Cisco-вский, и всё завелось.
Настройка hostname и IP адреса
Для смены hostname воспользуйтесь командой:
<Quidway>system-view
[Quidway]interface vlanif1
[Quidway-vlanif1]ip address 172.20.0.47 21
[Quidway-vlanif1]quit
Новый адрес применяется сразу, и в отличии от CISCO здесь не надо перезагружать интерфейс.
Настройка SNMP
У коммутаторов Huawei есть две особенности, о которых надо помнить, настраивая snmp. Во первых, если у вас включен snmp v3, то snmp v2c работать не будет. Во-вторых для snmp v2c при настройке на коммутаторе в консоле имя community надо указывать в кавычках, и в мониторилке (например Dude) оно тоже должно быть указано в кавычках (использовал двойные кавычки).
[Quidway]acl number 2100
[Quidway-acl-basic-2100]rule 1 permit source 172.20.0.33 0.0.0.0 // for one ip
Опционально можно добавить контактные данные в snmp.
[Quidway]snmp-agent sys-info contact X Division
[Quidway]snmp-agent sys-info location Kremlin
Настройка ssh
Генерим ключи, добавляем юзера, даём юзеру доступ к сервисам ssh(stelnet)+telnet.
[Quidway] rsa local-key-pair create
[Quidway]aaa
[Quidway-aaa]local-user admin password cipher YOURPASSWORD
[Quidway-aaa]local-user admin privelege level 3
[Quidway-aaa]local-user admin service-type ssh telnet
[Quidway-aaa]quit
[Quidway]stelnet server enable
[Quidway]ssh user admin authentication-type password
[Quidway]ssh user admin service-type stelnet
[Quidway]user-interface vty 0 4
[Quidway-ui-vty0-4]authentication-mode aaa
[Quidway-ui-vty0-4]protocol inbound ssh
Поднимаем веб-интерфейс
Файл с веб-интерфейсом (скрипты, js, css и т.д.) должен лежать в виде архива на устройстве. Просмотреть, что там лежит можно командой dir.
В моем случае у коммутатора было два вида интерфейса: classic (а-ля привет 90-е) и easyOperation (более-менее юзабельный). Можете сами визуально сравнить их.
Это classic интерфейс
А вот это EasyOperation
Почувствуйте разницу 🙂 Хотя лучш все равно в консоле.
Таблица аналогов CISCO-вских команд у HUAWEI
| CISCO | HUAWEI |
| ping | ping |
| traceroute | tracert |
| show | display |
| show interfaces | display interface |
| Show ip route | display routing-table |
| Show ip interface | Display ip interface |
| Show version | Display version |
| Show ip bgp | Display bgp routing-table |
| Show clock | Display clock |
| Show port | Display port-mapping |
| Show flash | dir flash: (on user view mode) |
| Show logging | Display logbuffer |
| Show snmp | Display snmp-agent statistics |
| Show frame-relay pvc | Display fr pvc-info |
| Show users | Display users |
| Show terminal length | screen-length disable |
| undo screen-length disable | |
| enable | Super |
| disable | Super 0 (number is privilege level from 0 to 3, where 3 is default and equivalent to “enable” on Cisco) |
| Conf t | System-view |
| exit | quit |
| end | return |
| Show policy-map interface | Display qos policy interface |
| send | send (on user view mode) |
| write terminal (sh run) | display current-configuration |
| Sh startup | Display saved-configuration |
| [no equivalent: shows the files used for startup] | Display startup |
| Write erase | Reset saved-configuration |
| Write mem (or wr or copy run start) | save |
| clear counters | reset (on user view mode) |
| Reset counters interface | |
| ? | ? |
| telnet | telnet |
| Enable secret (conf mode) | Super pass cipher (system mode) |
| Term mon | term debu |
| clock | clock |
| no | undo |
| debug / no debug | debugging / undo debugging |
| copy running-config | Save safely |
| terminal monitor | terminal monitor |
| terminal length | screen-length disable |
| undo screen-length disable | |
| terminal no monitor | undo terminal monitor |
| clear counters | reset counters interface |
| clear interface | reset counters interface |
| clear crypto | ipsec sa |
| ike sa | |
| clear access-list counters | reset acl counter all |
| reload | reboot |
| shutdown | shutdown |
| boot | boot bootrom |
| Aaa | hwtacacs scheme |
| terminal no monitor | undo terminal monitor |
| tacacs-server | hwtacacs scheme (in conf command) |
| snmp-server | tftp-server (in conf command) |
| router bgp | bgp |
| Router rip | rip |
| ip tacacs | hwtacacs nas-ip (this command doesn’t exist . ) |
| mtu | Mtu (this command doesn’t exist . ) |
| clear ip cef | reset ip fast-forwarding |
| clear ip route * | reset ip routing-table statistics protocol all |
| Clear ip bgp | Reset bgp all |
| Show tech | display diagnostic-information |
| Sh ip nat translation | Display nat session |
| Show Controller | display controller (but not relevant for non-modular chassis) |
| show dsl int atm 0 | display dsl status interface Atm 2/0 |
| sho atm pvc | Display atm pvc-info |
| debug pvc nego | Debug atm all (very dangerous – might crash router) |
| sho crypto isakmp sa | Display ike sa |
| sho crypto isakmp key | Display ike peer |
| sho crypto isakmp police | Display ike proposal |
Ссылки
Спасибо!
Если вам помогла статья, или вы хотите поддержать мои исследования и блог - вот лучший способ сделать это:
Как вариант просканировать сеть и по ARP таблице посмотреть по MAC адресам. В начале MAC адреса идёт префикс вендора.
Есть другие способы чтобы получить информацию о HBA, но удобнее использовать systool (пакет sysfsutils).
Найти WWN портов:
Сообщите эти значения администратору для настройки параметров доступа к вашему LUN
Определить статус портов:
Если статус Online и настроен доступ на СХД, то можно перезагрузить модуль адаптера и попытаться увидеть ваш LUN
Это необходимо для распределения нагрузки и отказоустойчивости.
- Какое же из устройств использовать? - Если вы просто будете использовать в таком варианте одно из устройств, то это означает использование только одного пути.
Для использования всех нужно использовать либо службу Multipath или Huawei OceanStor UltraPath
Многопутевой ввод-вывод (Multipath I/O)
Использовать много-путевой доступ необходимо даже в том случае если на вашем сервере используется 1 порт.
Иначе, например, в случае обновления прошивки на одном из контроллеров СХД произойдет временное отключение вашего сервера от СХД и данные на вашем LUN могу быть повреждены.
Многопутевой ввод-вывод (Multipath I/O) — технология подключения узлов сети хранения данных с использованием нескольких маршрутов. В случае отказа одного из контроллеров, операционная система будет использовать другой для доступа к устройству. Это повышает отказоустойчивость системы и позволяет распределять нагрузку.
Multipath устройства объединяются в одно устройство с помощью специализированного программного обеспечения в новое устройство. Multipath обеспечивает выбор пути и переключение на новый маршрут при отказе текущего. Это происходит невидимо для программ и процессов использующих это устройство. Кроме того Multipath способен распределять передачу данных по разным путям посредством различных алгоритмов, например:
round-robin - Цикл по всем маршрутам в группе маршрутов, посылая одинаковый поток в каждый) queue-length Посылать следующую порцию данных по маршруту с наименьшим количеством невыполненных запросов service-time - Посылать следующую порцию данных по маршруту с наименьшими задержками, которые определяются делением общего объема невыполненного ввода/вывода на каждом маршруте на их относительную пропускную способность.Преимущества Huawei UltraPath
Установка OceanStor UltraPath
Запросить у службы поддержки ссылку на пакет OceanStor UltraPath соответствующий версии вашей ОС.
В ходе установки вам будет предложено выбрать опции:
Если система у вас установлена на локальном HDD, то ваш выбор должен быть - 1: Boot from local Если ваша система установливалась на диск доступный по Fibre Channel или iSCSI, то ваш выбор должен быть - 2: Boot from SAN
Следующий шаг - согласиться или отказаться от перезагрузки системы.
Если для подключения к системе хранения используются HBA адаптеры HCA, QLogic или Emulex, мы рекомендуем установить значение N.
Установите следующие параметры драйвера HBA адаптера:
Например для QLogic (qla2xxx) в файле /etc/modprobe.d/nxupmodules.conf следует добавить строки, если их там нет:
Для программного адаптера Linux-iscsi (Red Hat AS4) в файле /etc/iscsi.conf должны быть параметры:
Для программного адаптера open-iscsi (RHEL-7, Centos) в файле /etc/iscsi/iscsid.conf должны быть параметры:
Убедитесь, что UltraPath работает
lsscsi | grep updisk [8:0:0:1] disk up updisk 4303 /dev/sdc
В данном случае виртуальный диск созданный UltraPath имеет имя /dev/sdc
В дальнейшем вы можете использовать его для всех нужд
Создать файловую систему XFS:
Настройка UltraPath
Для управления параметрами используется утилита upadmin
Конфигурация по умолчанию после установки:
Здесь стоит изменить параметр Working Mode чтобы данные одновременно передавались по всем путям
Контроль I/O по путям для LUN с идентификатором 0:
Пересканировать SCSI
Если у вас изменился список scsi устройств (добавили LUN), то система не увидит их сама В дистрибутивах основанных на Red Hat есть скрипт:
Читайте также: