О том, что скоро наступит светлое будущее и всех нас ждут российские операционные системы, базы данных и прочие нужные вещи, телевизор уже всем рассказал.
В реальности все, как обычно, обстоит несколько иначе…
Несколько лет назад компания Softline начала активно мониторить рынок российских ИТ-решений, чтобы удовлетворить спрос со стороны государственных (и не только) компаний на импортозамещающую продукцию в ИТ. Ну ведь должно же что-то быть, правда?
Так как сегодня пишем про СХД, значит и расскажем о нашем опыте как мы искали, тестировали и внедряли СХД российского производителя компании AERODISK.
Но, прежде чем познакомиться с данным вендором, мы прошли
А теперь сразу минуточку внимания:
Во-первых, мы совсем не против OEM-бизнеса, это нормально и практикуется во всем мире. К примеру, тот-же HP давно и успешно OEM-ит СХД DotHill, продавая ее по всему миру как свою и всем все нравится.
Во-вторых, мы против только откровенного обмана (я думаю, тут с нами согласятся все).
Мы не будем тут приводить названия организаций, которые ведут себя плохо, обманом выдавая себя за отечественных производителей. Мы не хотим создавать никому антирекламу, но, к сожалению, такие компании есть, и они у всех на слуху.
Попытка номер раз
Начав поиск, мы первоначально наткнулись на целую кучу так называемых «российских СХД», которые по всем бумагам и картинкам «наши», продаются под «импортозамещение», а на деле и оборудование и интеллект либо китайские, либо американские.
Ну, чёрт бы с ним с оборудованием, понятное дело, что даже американские производители делают свое железо в Азии, сейчас это норма, но ПО-то кто мешает написать?
Попытка номер два
Мы, конечно, расстроились, но продолжили искать. Вскоре мы обнаружили несколько российских решений, которые действительно разработаны были у нас, но тесты показали, что они страдают одной из двух (или сразу двумя) болезней.
- Решения сырые
- Решения не для серьезных (или для нишевых) задач
Очевидно, что работать серьезно мы с такими решениями не могли. Опять неуд.
Попытка номер три
Расстроившись ещё больше, мы продолжили есть кактус. В этот момент (шел конец 2017 года) у нас появился крупный федеральный проект, где нужно было максимально использовать российские технологии. Еще шла стадия проектирования: закладывались основные технические решения. Эта была часть федерального проекта «Безопасный город» в одном из городов – хозяев ЧМ 2018.
Концепция «Безопасного города» подразумевает объединение всех ответственных служб безопасности в единое направление с тесной интеграцией ИТ-систем. Это помогает гораздо быстрее реагировать на инциденты, а в некоторых случаях даже предотвращать их.
Технически суть проекта в том, что в городе все обвешивается камерами (несколько тысяч камер), и эти камеры, используя умную систему видеонаблюдения, автоматически фиксируют опасные или потенциально опасные события и в хорошем разрешении непрерывно пишут данные в ЦОД. В онлайн-режиме аналитика событий с камер выводится на пульты экстренных служб, и, кроме того, в ЦОД-е записи с камер хранятся минимум один месяц.
В любой момент сотрудник правоохранительных органов может обратиться к оператору услуги и максимально быстро получить видео из любой точки за последний месяц для дальнейшего анализа. Требования к доступности и производительности (несколько тысяч камер хорошего разрешения – это не фунт изюма, как вы поняли) в таком проекте максимальны. Если нужное видео потеряется или не так запишется, оператор услуги может на полном серьезе уехать отдыхать на курорты солнечного Магадана.
Конечный заказчик (оператор услуги) просил по возможности (без ущерба качеству) использовать российские решения там, где это возможно, поскольку с него же потом собирались спросить: «а что ты сделал для импортозамещения?». А краснеть он перед большими начальниками ох как не хотел.
С системами видеонаблюдения проблем не было, т.к. есть много российских решений, выбор большой, и в данном случае было использовано проверенное решение. А вот с СХД (поскольку наши поиски не увенчались успехом) мы были настроены на использование давно знакомого иностранного решения. И тогда один из наших партнеров по проекту предложил использовать для уровня хранения российскую СХД AERODISK.
Мы (Softline) на тот момент, конечно, знали, что есть такой производитель, и что это не OEM. Отзывы о нем слышали разные: и хорошие, и не очень, поэтому однозначного впечатления у нас не было. До его тестирования мы не дошли, поскольку тестирование решений других российских разработчиков (см. попытка номер два) не удалось, и мы на время приостановили активность из-за постоянных провалов.
Но предложение было сделано, заказчик воспринял идею на ура. А мы отправились выяснять, что за СХД делает AERODISK, и решили их навестить.
Посещением компании AERODISK мы остались вполне довольны. Нам показали систему в работе, демо-центр, а также дали пообщаться с разработчиками, которые «вот этими вот руками» делают будущее.
Мы попросили AERODISK организовать тестовую лабораторию специально для этого проекта и вместе с выбранной системой видеонаблюдения эмулировать продуктивную нагрузку. Специфичность задачи состояла в том, что, кроме обычной потоковой записи видео, к потоку постоянной записи добавляются задачи по чтению и перезаписи данных на основе проведенного анализа. Зная этот профиль нагрузки, мы на протяжении нескольких недель гоняли СХД AERODISK и в хвост, и в гриву. В целом, результатами остались мы довольны, система в ряде случаев даже превосходила иностранных производителей, но были и недочеты. Но все они сводились в основном к мелким багам в интерфейсе, которые оперативно были исправлены тех. поддержкой производителя.
Итог теста был такой:
- Ничего не сломалось, хотя мы ломали
- По ходу теста поддержка работала на хорошем уровне
- Производительность для нашей задачи была достаточна
- Мы поняли, что мы как системный интегратор вполне можем систему поддерживать самостоятельно (для нас это важный критерий)
Мы приняли решение идти в этот проект с СХД AERODISK и со стандартными x-86 серверами, подключенными к СХД по Fiber Channel и по Ethernet 10Gbit. Предстояло собрать два отказоустойчивых кластера, которые будут параллельно обслуживать городские видеокамеры.
Внедрение
Проектное решение разрабатывалось с нуля, и толком ни у нас, ни у нашего партнера, ни у оператора услуги подобного опыта не было. Понятно, что были использованы различные бэст практисы и прочая теория, но, как говорят у военных, «любой план хорош до первого выстрела». Проект на бумаге выглядел идеально и был утвержден. Смущало то, что AERODISK не участвовал в проектировании, по причине того, что в проекте появился в последний момент и что-то переутвердить уже было невозможно без переноса сроков (а срок ЧМ-2018 перенести мы не можем)))).
Комплекс решений был поставлен, настроен согласно проектным документам и введен в опытную эксплуатацию, которая должна была идти несколько месяцев. Началось все очень хорошо и обе системы хранения за первый месяц были заполнены данными с видеокамер. Полет был нормальный, все как на бумаге. Мы были очень рады, но еще не знали, что настоящие проблемы нас ждали ещё впереди.
Мы уже было расслабились, но под конец второго месяца опытной эксплуатации от оператора услуги стали поступать жалобы на производительность и нестабильность работы системы в целом.
Мы срочно привлекли поставщика решения для видеонаблюдения и AERODISK к решению проблемы. На тот момент мы ждали, что начнется «пинг понг», типа этого:
К нашему удивлению этого не случилось, и оба вендора с головой ушли в диагностику проблемы. На следующий день был выдан диагноз. Причина проблем с производительностью была в некорректной настройке СХД. Сработало то, что нас смутило с самого начала: физически не было возможности привлечь производителя СХД к проектированию, и именно этот участок был спроектирован неверно, без учета особенностей СХД AERODISK. Мы в тот момент даже обрадовались, потому что «ну раз криво настроено, так давайте перенастроим, в чем проблема то :)?»
Но не тут-то было. Проблема заключалась в том, что видео с камер писались в основном на файловые шары SMB, которые были презентованы с СХД серверам видеонаблюдения, и именно в этом был корень зла, а по правильному для видеонаблюдения нужно презентовать блочные устройства и форматировать их уже на уровне серверов в локальные файловые системы. Казалось бы, в чем проблема, создаем LUNы и отдаем серверам, но нет. Поскольку за первый месяц работы весь полезный объем обеих СХД был уже занят, то LUN-ы банально негде создавать. Места нет, а удалять старые видео, чтобы освободить место нельзя, ибо «посодют». Ну и бэкапы тут не помогут, что очевидно, а репликация не была заложена в проект.
Докупить ещё столько же объема (пол петабайта) бюджета уже не было, а очистить текущее дисковое пространство было нельзя. Вариант использовать временное пространство в нашем облаке не подходил, поскольку будут слишком большие задержки при таких объемах записи. То, что так хорошо начиналось, подходило к ужасному концу.
Развязочка
Но помощь все-таки пришла. AERODISK предложил поставить на время перенастройки СХД рядом еще один свой массив аналогичной емкости и производительности, перенаправить всю запись на него, подождать один месяц, когда данные с неверно настроенных СХД автоматически удалятся. После этого, пока видеоданные пишутся на временную СХД, а постоянные СХД освободились, следовало выполнить корректную настройку блочного доступа на свободных СХД. Ну а потом выполнить все в обратном порядке. Как вы поняли все эти операции следовало выполнять «без единого разрыва)))», то есть без остановки записи с видеокамер.
Самостоятельно провернуть такую спец. операцию мы немного боялись. Поэтому AERODISK (за что ему огромное спасибо) кроме железа несколько раз командировал двух инженеров для выполнения этих работ.
Переключение на временную СХД, перенастройка и обратное переключение было выполнено без каких-либо остановок. Производительность СХД и комплекса в целом нормализовалась. Оператор услуги сиял от счастья, поскольку уже почти смирился с провалом проекта.
На текущий момент комплекс «Безопасный город» введен в эксплуатацию, мы получили бесценный опыт, а программно-аппаратный комплекс, использованный в этом проекте взят за эталон для последующих применений в других городах нашей страны.
Выводы
Итак, мы изучили рынок российских систем хранения данных, прошлись по OEM-ным «фэйкам», сырым решениям, смогли все-таки найти серьезного игрока на этом рынке – компанию AERODISK, чей продукт СХД ENGINE N-серии по нашему опыту может смело конкурировать с более именитыми зарубежными решениями. Да, реализация большого и сложного проекта не вся прошла гладко (а бывает по-другому?), но результат в итоге получился на наш взгляд отличный. Можно с уверенностью сказать, что за импортозамещение в направлении систем хранения данных Родина может не волноваться.
Комментарии (31)
nApoBo3
16.01.2019 13:46Не очень понятен опус про «посодют», особенно в разрезе опытной эксплуатации.
Softliner Автор
16.01.2019 14:01Если бы опытная эксплуатация не дала бы результата, проект признан был бы провальным (т.к. времени переиграть уже не было бы). ЧМ остался бы без видеонаблюдения, не смотря на то, что деньги давно на это выделены. Вот вам и повод съездить отдохнуть на курорты солнечного Магадана :)
tangro
16.01.2019 13:55Вообще редко что такого масштаба получается методом «купить и включить». Интегратор, глубоко разбирающийся в особенностях системы, нужен всегда.
CherryPah
17.01.2019 09:07Что такое такой масштаб вашем понимании? Полпетабайтные схд с учётом нынешних объемом данных и масштабами их роста — не самые большие объемы. Нагрузка на них от камер ВН величина не заоблачная, никаких сотен тысяч иопс там не нужно. И величина эта линейная и легко вычисляемая.
А уж использование файлового а не блочного доступа для таких целей — полноценный факап интегратора.
Если что я в всаас работаю, мнение не из Гугла беруNaves
17.01.2019 09:50А уж использование файлового а не блочного доступа для таких целей — полноценный факап интегратора.
А можно с этого места поподробней, почему? Сколько не пытался загуглить обоснование этого или сравнение производительности, ничего не нашёл.
Наш интригатор утверждал ровно обратное, и в итоге наступил на грабли в другом месте.
Кроме того, что для файлового доступа тратится оперативная память самой хранилки, больше никаких доводов не нахожу.
FYR
17.01.2019 13:32если вы работаете с файлами — то задача размещения этих файлов по блокам решается СХД наверняка общего назначения. А она ничего не знает ни о будущих размерах файлов ни о порядке доступа к ним. Ну и тут сразу вопрос: а какая СХД и какая там файловая система и подходит ли она для вашего профиля нагрузки. (много мелких файлов / несколько но огромных). Кроме того плюсом идет затраты на обеспечение синхронизации доступа к файлам с нескольких инициаторов.
При блочном доступе — выбор ФС и порядок доступа определяется клиентом который знает что у него там за профиль нагрузки. Плюсом в помощь кэш операционной системы или вообще директная запись в блоки. А со стороны СХД совcем не надо заботиться о синхронизации доступа к LUN.Naves
17.01.2019 16:05Так то оно понятно, но в данном случае у нас явно сказано про систему видеонаблюдения. Обычно это много крупных файлов. Если запись по движению, то минимальный сегмент в среднем 10 секунд потока от 2мбит, или размером конечного файла от 2,5мб. Если постоянная запись, то обычно режут примерно по 100-200мб файлы.
Далее, если у нас куча разных серверов, то обычно все-таки делается соответственное количество LUN-ов кратное количеству серверов. Например, один сервер пишет в три LUN, долгое/среднее/короткое время жизни записей.
Если сервер видео на базе windows, то и выбора типа ФС особо и нет, только размер блока. Обычно размер блока можно указать и на самих хранилках при их настройке.
Еще что-то не припоминаю импортозамещенных программ для видео с прямой записью на устройства, обычно все пишут в файлы. Китайские видеорегистраторы для аналоговых камер раньше работали без ФС.
В чем явное преимущество блочного доступа по сравнению с файловым еще не ясно.FYR
18.01.2019 10:09Данные с камер надо принять… наверное по ip мелкими фрагментами этих камер много… 10 тысяч. если каждая будет писать в свой пусть большой файл… это 10 тысяч iops… пусть и последовательно. Потом удалять — это фрагментация…
Я не спорю что решить с помощью NAS это можно. Но не так с наскоку… Придется группировать данные разных камер в один огромный файл. каким то образом строить в нем систему ссылок.
FYR
17.01.2019 13:25Нагрузка от десятка видеокамер — конечно не заоблачная… Беда в том что этих камер «несколько тысяч» раскиданных по всему городу…
Полпетабайта в месяц это примерно 200 мегабайт в секунду… Тю… пара дисков в зеркале…
Однако несколько тысяч камер наверняка гонят данные покадрово, пакетиками, да еще надо складировать наверняка каждую камеру отдельно… Вот вам уже «несколько тысяч IOPS». Если данные прибегают по IP то пакет килобайт-полтора… В идеальном H264overRTP 65k. Ну то есть от сотни тысяч до поллумиллиона IOPS.
Так что просто получить и просто записать в файлики «в лоб» уже не получается. У нас ведь не SSD… это несколько тысяч шпинделей надо. Придется аггрегировать/копить/последовательно писать/группировать.
Поэтому кстати и не файлы ибо блочные устройства последовательны и задачу группировки запросов будет решать не СХД, а файловая система на сервере, который хотябы представляет с какими данными работает сервер и как можно оптимизировать группировку. Ну и минус разные расходы на сетевые вещи самбы.
P.S. Я не сотрудник SoftLine и отношения к этой СХД не имеюNaves
17.01.2019 16:41Простите, но покадрово никто не пишет, именно чтобы не было «несколько тысяч IOPS»
задачу группировки запросов будет решать не СХД, а файловая система на сервере, который хотябы представляет с какими данными работает сервер и как можно оптимизировать группировку.
Совсем не факт, что сервер настроенный кое-как в наших реалиях будет это делать лучше, чем хранилище, у которого часто есть выбор оптимизации для нужного профиля нагрузки.
Опять-таки команда «записать это немедленно» с верхнего уровня ФС не уйдет мгновенно на шпиндели, а встанет как минимум в очереди в RAID или HBA-контроллере.
Можно настроить блочное подключение к хранилищу на 10 серверах ивыбрать по умолчанию NTFSнеправильно настроить ФС, что на каждую команду записи данных, будет уходить две команды записи в ФС и ее журнал. Или просто отправлять данные по samba-протоколу, и ОС хранилища будет самостоятельно делать commit на уровне своей ФСFYR
18.01.2019 10:18Ну как то сравнивать ситуацию «тупой клиент / умная схд» и «умный клиент /тупая схд» несколько неправильно.
И кстати не сравнивал iSCSI (SCSI over IP) и Samba (тоже over IP) какие там будут накладные расходы. Но вот если у нас будет FC то там как раз плюх много. Тот же самый Multipath для пропускной способности и резервирования линков…
CherryPah
18.01.2019 09:53+1Никакой покадровой записи, видеопоток это же не 24жпега/сек.
I/P/B и прочие кейфремы и дельта между ними — вот основная составляющая h264/265
Камеры не пишут прямо на схд, между ними есть «прослойка» в виде серверной части видеонаблюдательного ПО, котораязанимается аналититкой, метадатой, прочейчерноймагией,в упрощенном для интересующей нас части формирует сегменты и отправляет их на запись на схд. Играясь с параметрами этих сегментов, выбором файловой системы и ее параметрами — в итоге получается оптимальная производительность и задержки.
Naves
Совсем не факт, что сервер настроенный кое-как в наших реалиях будет это делать лучше, чем хранилище, у которого часто есть выбор оптимизации для нужного профиля нагрузки.
Имея вводную что у нас есть плохой сервер и принять на веру что вендор схд заложил идеальный профиль для записи внутри своей железки — тогда да, файловый доступ будет лучше. Если добавить еще виндовый сервак и бесплатное по, шедшее в комплекте с китайскими камерами — то SMB вообще становится единственным рабочим вариантом чтобы не уехать в солнечный Магадан.
Блочный доступ более производительный ( да, можно подобрать профиль где файловый выиграет, но профиль мы выбирать особо не можем — камеры и потоки с них никуда не денутся) и дает возможность как и самоличный выбор фс, так и ее тюнинг.
Файловый позволяет делегировать как часть своей ответственности на вендора (ну они там наверное лучше знают что и как мне писать), так и часть возникающих проблем (я не знаю почему скорость деградировала, давайте вызывать представителей вендора, пусть они отвечают)
Softliner Автор
16.01.2019 14:16RAIDIX это ПО (SDS). К нему еще нужно оборудование и поддержка этого оборудования. В рамках этого проекта SDS (ни российский, ни зарубежный) не рассматривался.
Naves
17.01.2019 21:521) Ни одной технической детали
Какие диски были, какой примерно уровень RAID
Сколько в сумме было камер, средний/общий трафик с них.
2) Почему перешли с SMB на iSCSI, и какое обоснование для этого. Какая ФС была сверху.
3) экономика решения
полпетабайта это 500 Терабайт?
6Tb SAS HGST 3.5", 7200 стоит примерно 20 тыс рублей.
один диск примерно дает 5,4Tb объема, берем пусть 120 дисков, итого за диски 2,4 млн рублей без учета скидок.
Хранилка на 24 дисков с контроллером стоит меньше 2 млн рублей, но нам нужен по факту один контроллер на несколько модулей расширения, каждый на 24 диска чуть меньше пол млн рублей, итого: голова 24 диска + 4 модулей по 24 диска = 2+4*0,5=4 млн рублей на полку на 120 дисков.
например, моделиP600Q-D424 и J300Q-D224Barabek
17.01.2019 08:31Скажите, а есть ли точное определение, что такое российская СХД? Сколько в ней чего должно быть российского? Бывают решения иностранных брендов, но софт пишут российские команды. Хотя и не весь. И если такая сисиема поставляется российским интегратором, но в кишочках иностранные строчки кода, написанные простыми питерскими программистами, все это под управлением открытой линукс-системы (наверное, при желании, можно и соболь какой-нибудь заюзать), вот как оценить импортозаместимость такого решения?
Softliner Автор
17.01.2019 16:39Точного определения нет, так как это только зарождающийся рынок у нас. 20+ лет у нас в стране почти не было системной разработки (привет Грефу: «мы все купим»).
По факту импортозамещаемость сейчас можно измерить интеллектуальной собственностью.
Если интеллект принадлежит российской компании (со всеми исходниками), то продукт российский. А если ещё и продукт работает, то совсем хорошо.
Железо в этом случае вторично, поскольку все бренды (втч американские) сейчас выпускают железо на азиатских заводах, да и в России все-равно пока нет налаженного выпуска x-86 железа.
Те же Байкалы с Эльбрусами делают по контракту в Азии.
blind_oracle
17.01.2019 20:20Какой магией байкалы и эльбрусы стали х86?..
Softliner Автор
18.01.2019 12:01Само собой нет.
Эльбрус и Байкал приведены в качестве примера того, что даже полноценная отечественная разработка (в первую очередь Эльбрус) физически делается в Азии в силу отсутствия в РФ советующих производственных мощностей.
IgorPie
17.01.2019 12:36«Мы не будем тут приводить названия организаций, которые ведут себя плохо, обманом выдавая себя за отечественных производителей»
может, не надо помогать им мошенничать? Заодно, другие интеграторы будут знать куда идти не надо.
Наверняка же есть маркетинговая табличка с перечнем продуктов и «нюансами»?Softliner Автор
17.01.2019 18:29Если мы напишем конкретные компании, то это будет анти-реклама, а мы в статье обещали этим не заниматься, поэтому извините :).
amarao
А почему вы не делали нагрузочное тестирование перед продакшеном в конфигурации продакшена? Те же камеры можно было спокойно заменить пишущими моками и получить тот же самый факап в лабораторных условиях.
vesper-bot
Факап, по статье, появился спустя 50 дней — тупо времени не было так долго гонять СХД в правильной конфигурации.
amarao
Поздняя регрессия, это понятно. Но когда его в хвост и гриву гоняли в лаборатории, это делали на самбе или на scsi/iscsi/fc (т.е. на блоках)?
Softliner Автор
По сути было 2 нагрузочных теста. Лабораторный, где все тоже самое, но в меньших объемах, где было все ок и непосредственно опытная эксплуатация у заказчика (несколько месяцев перед продакшеном). Период в которой всплыла проблема, это как раз опытная эксплуатация у заказчика, но еще не продакшен.
amarao
Не сходится. Если это опытная эксплуатация, то накопленные данные можно дропать. А у вас в посте написано, что дропать нельзя было. Звучит так, что оптыная эксплуатация случайно была объявлена продакшеном.
(Типовое «какой стенд, мы уже клиентов туда запустили»).
Softliner Автор
Эта была одна из особенностей проекта. Уже во время опытной эксплуатации вежливые люди во всю использовали видео для своей работы. С этим ни мы, ни оператор услуг сделать ничего не могли.
FYR
Дык так оно в этой сфере не бывает. «Опытная» означает что вас пустят на площадку, дадут работать с оборудованием/софтом, ну а если данные таки потеряют то грозный дядя майор не отправит вас на этап, а просто будет очень неприятно.
Еще это означает что у вас таки есть шанс согласовать простой на несколько минут на переключение чего либо куда либо.
Еще это означает что комплекс не принят на приемосдаточных испытаниях и денег разработчик могет и не получить.
А ну и еще означает что «вежливые люди» будут знать, что к комплексу имеют доступ разработчики и никаких особо секретных работ, которые могут раскрыть оперативные мероприятия проводить не надо.
Но просто так грохнуть данные вам не разрешат…