Сегодня мы расскажем о героических буднях админов и системах хранения данных. В рамках этой статьи мы расскажем две реальные истории внедрения СХД и попробуем поделиться своим опытом внедрения и эксплуатации СХД решений. Имена участников конечно же вымышлены.

История 1. Как закалить админа

Начались суровые будни администратора Пети, и вот вечером приехала очередная партия оборудования вместе с СХД, но уже слышны стоны пользователей о том, когда новые ресурсы СХД будут им выданы. И вот системный администратор, невзирая на погоду и завершившийся рабочий день, уже бежит в свой ЦОД (или серверную, у кого как). Ведь там находится его главная цель — СХД, про которую он уже много читал на сайте производителя, практически изучил по буклетам, как она работает. Ведь именно он защищал покупку этой системы у своего ИТ-директора и приводил тысячу «за» и немного «против», и вот наступил тот самый момент, счастье совсем близко.

Долгожданная встреча

Заходя в серверную, он обнаруживает долгожданную коробку с СХД. Мгновения, и вот система уже сияет и блестит, весело переливается логотип, освещаемый светодиодной лентой общего освещения. Админ знает весь стандарт TIA/EIA-569 и, конечно, уже предусмотрел, что пол в серверной выдержит этого «зверя», ведь СХД весит ни много и ни мало с детёныша лесного слона, попробуй-ка его подними. Петя мечтает, как в Web-консоли СХД он увидит новое неразмеченное пространство своего хранилища, но возникает вопрос, а как же его подключить к существующей системе и как выполнить апгрейд?

На сцене новый герой

Петя спокоен, ему на выручку приходит сервисный инженер Коля от производителя СХД. Тот самый, кто проходил важные курсы по обслуживанию СХД (или не проходил, всё бывает в первый раз когда-то). Он несёт секретную документацию, в которой сказано и иногда показано, как нужно включить массу джамперов и подключить соединительные провода, чтобы выполнить этот апгрейд. Успешно подключив к электричеству свою СХД, предварительно сбегав на ближайший рынок и поменяв розетку с двухфазной схемы включения на трёхфазную, как того требует документация, Петя и Коля с замиранием сердца включают новую систему. И вдруг замечают, что основная система переходит в режим Recovery, который означает серьёзный системный сбой. Звонит Юрий Петрович, начальник Пети, и услышав, что всё работает так, как и было запланировано, переходит в иное измерение, но со 100%-ным возвратом в прежнее состояние завтра к 8.00.

Бурундуки спешат на помощь

Коля сообщает Петру, что безвыходных ситуаций не бывает, ведь существует круглосуточная поддержка, и он позвонит сейчас туда ночью и спросит, что ему делать, так как в документации большими красными буквами чётко указано — «CONTACT SUPPORT, FURTHER ACTIONS MAY CAUSE SERIOUS DAMAGE TO YOUR HARDWARE». Дозвонившись до поддержки только около КПП охраны, так как зоны приёма больше нигде нет, Коля слышит приятный голос на английском в своём телефоне, который обещает незамедлительно помочь при условии, если Коля пришлёт несколько мегабайт отладочной информации по электронной почте. Предварительно записав обратный почтовый адрес своего коллеги из солнечной Индии, Николай ждёт, когда же письмо покинет папку «Исходящие», и вкладывает в это все свои силы, чтобы оно всё-таки ушло к адресату. Петя не теряет время даром и проверяет, как работают его системы, вдруг «отъехали» диски или ещё что-нибудь. Получив ответ, Коля начинает вчитываться в историю своих действий и обнаруживает, что процедура апгрейда в документации вежливо рекомендовала подключить провода к другим разъёмам в СХД, а также сообщение: «WARNING! CABLE PLUGGED INCORRECTLY MAY CAUSE SERIOUS DAMAGE TO YOUR HARDWARE».

«Эврика!» — восклицает Коля.

«Да как же так? — парирует в ответ Петя и продолжает. — Моя СХД система стоит как самолёт «боинг», ведь можно же предусмотреть наклейку и поместить рядом с нужным разъёмом, чтобы не перепутать его при включении».

Ситуация вскоре меняется, Коля выполнил свою работу, и СХД переходит в штатный режим. Все системы работают как и положено, и при этом даже не произошло перегрузки ИБП, так как Петя всё рассчитал заранее, когда планировал потребляемую мощность нового оборудования.
И вот долгожданный момент наступил. В 8.00 на плановом совещании Петя докладывает, что СХД система готова к использованию.

Поработаем над ошибками?

История, которую мы рассказали в самом начале статьи, взята из реальной жизненной ситуации одной крупной компании (имена вымышлены), которая приобрела СХД. На самом деле таких историй много, и нам есть что рассказать хотя бы ради того, чтобы показать, как наши соотечественники могут решать сложные проблемы. Ведь зачастую иностранцу в голову никогда не придёт идея, как решить сложную проблему без чёткой и пошаговой инструкции удалённой технической поддержки.

Попробуем собрать воедино все проблемы, вот некоторые из них:

1. Человеческий фактор — оказалось, что есть только один опытный администратор в штате компании.
2. Неготовность инженерной инфраструктуры — не готова система электропитания, так как не оказалось нужного трёхфазного разъёма для подключения СХД.
3. Недостаток квалификации — сервисный инженер от вендора СХД не имеет достаточной квалификации.
4. Неэффективная техническая поддержка — цепочка удалённой сервисной поддержки оказалось очень сложной в процессе эксплуатации.
5. «Последняя миля» — процесс сборки СХД сложный, а также плохо документирован, что послужило причиной фатальной ошибки инженера, которая по сообщению из документации могла привести к остановке СХД.

Неужели у нас всё ещё нет грамотных сервисных инженеров ?

Многие захотят ответить, что у нас такой проблемы нет, так как любой уважающий себя покупатель СХД всегда обучит свой персонал и оплатит курсы у вендора. Объективно, не все проблемы можно просто решить, послав на курсы от вендора СХД своего администратора. Так происходит по ряду причин:

1. Обучающие курсы от производителя не обучают пусконаладке СХД.
2. Задача обучающих курсов — привить навык «пользователя», который не должен сломать систему, но должен выполнять простые обязанности поддерживания СХД системы в рабочем состоянии.
3. Курсы мотивируют администраторов развиваться в направлении данного вендора СХД и формируют сообщество поклонников данного вендора, но не формируют объективную точку зрения на СХД, т.е. не формируют базовые знания о принципах работы СХД и его внутреннем устройстве.

В общем и целом практически все обучающие курсы СХД вендоров не ставят перед собой задачу подготовить автономного летающего «Карлсона» с реактивным двигателем и разводным ключом, способного в любой момент прийти на помощь и поменять сломанный двигатель летящего самолёта.

А что же хочет вендор СХД?

У вендора существует вполне конкретная цель — сформировать чёткое представление о своём продукте и предложить свою формулировку многочисленных терминов, таких как терминология RAID и многих других особенностей, а главное — ненавязчиво сформировать мнение о своей незаменимости.

Действительно, на практике любой российский системный интегратор полностью зависит от компании вендора СХД, и об этом нужно сказать честно. Даже наличие сервисных центров у нас в стране не меняет ситуацию. Причина простая — технология СХД у иностранных вендоров разрабатывается не в России, а за рубежом. Поэтому реальная экспертиза у представителей глобальных вендоров отсутствует локально в России. У нас просто нет таких инженеров, которые способны разработать программное обеспечение для СХД, выполнить диагностику и ремонт сложных элементов СХД (контроллеров, дисков).

Ситуация меняется с появлением небольших коммерческих организаций, которые начинают производить собственные варианты СХД, и наш пример не единственный в сегодняшней практике. Мы хотим сказать сообществу, что проектировать свои СХД можно с учётом нынешних условий рынка в России, и это нам по плечу.

Недостаток квалификации и что в итоге мы получаем на практике?

Один администратор учился на курсах у вендора А, другой администратор — у вендора В. И решили они обсудить, как устроен RAID60 и сколько дисков в нём должно быть, и не смогли они договориться. А когда речь пошла о конфигурации дисков, то каждый защищал свою систему и вендора.


Информация об устройстве СХД у различных вендоров устроена таким образом, чтобы потребитель смог разобраться в функциональном назначении той или иной части СХД, но не смог разобраться в принципах функционирования этой сложной системы.

Рассмотрим один простой практический пример

Использование «дальнобойного» оптического SFP трансивера обязывает администратора знать, какие существуют рабочие длины волн и, соответственно, какие типы оптоволоконного кабеля данный трансивер поддерживает. Простая ошибка в выборе оптического кабеля заставит потратить массу времени на поиск причин проблемы производительности в СХД, обращаясь в техническую поддержку вендора, когда реальная причина находится на поверхности.

Таким образом, кроме обычных навыков настройки СХД, требуются базовые инженерные знания в области стандартов передачи данных, протоколов передачи данных, которые, к сожалению, не преподаются в полном объёме на курсах вендоров СХД. Причина такого явления банальна — вендоры не могут раскрывать особенности устройства компонентов своих СХД, так как часть заявленных ими характеристик в маркетинговых статьях может оказаться неподтверждённой.
На наш взгляд, многие проблемы, которые встречаются в обслуживании СХД систем, могут и должны выявляться и диагностироваться автоматически.

Как можно защититься от таких проблем?

Решение таких проблем на наш взгляд может быть только в новых знаниях и опыте.

Именно поэтому мы разработали SDK, который позволяет на низком уровне контроллировать работу операций ввода-вывода на уровне SCSI команд. Используя Fibre Channel адаптеры компании Broadcom, мы получаем всю необходимую информацию о состоянии соединения на канальном уровне. В рамках нашего SDK реализованы практически все команды стандарта SCSI SPC-3. Используя наш SDK, можно эмулировать SCSI устройства (disk, VTL) и анализировать проблемные области в сети SAN.

А есть ли пытливость ума у «российского» инженера?

Если рассматривать вопросы организации RAID в СХД различных вендоров, то причина споров, на наш взгляд, просто в нежелании разобраться в сути вопроса. Взглянув на статью «A Case for Redundant Arrays of Inexpensive Disks (RAID)» инженеров David Patterson, Garth A. Gibson, и Randy Katz, которые описали принципы RAID и его варианты, можно почерпнуть всю информацию об устройстве RAID, но не нужно брать за аксиому частные инженерные решения вендоров СХД. Безусловно, таких частных вопросов и различий у вендоров СХД очень много. Иногда базовые знания о принципах функционирования той или иной системы помогают глубже вникнуть в суть проблемы и разобраться в сложной ситуации.

Что в имени тебе моём, ты оцени СХД объём

Компании-вендоры формулируют свои принципы функционирования RAID, исходя из своих коммерческих выгод, взять хотя бы расчёт ёмкости хранения, когда одному мегабайту приравнивается тысяча килобайт хранимой информации. Нетрудно подсчитать убытки от таких мнимых расчётов, когда клиент оплачивает именно реальные гигабайты, но ему их систематически недодают.

Наш принцип состоит в том, чтобы оценивать различные СХД системы на одинаковых весах, т.е. исходя из результата, который они позволяют получить. Конечно, совокупность признаков, которые оценивают потребители, у всех разная, и в неё входят: общая стоимость владения, стоимость апгрейда, стоимость технической поддержки и т.д.

Оценивая СХД системы, мы рекомендуем использовать следующие подходы:

1. Использовать одинаковый инструмент для нагрузочного тестирования СХД (собственной разработки, fio и др.)
2. Зафиксировать версию микрокода, которая установлена на СХД в момент тестирования.
3. Проверять обязательно версии микрокодов дисков и фиксировать их в отчёте.
4. Использовать тесты с реальными системами и не ограничиваться только синтетическими тестами.

Возникает вопрос, а какой из перечисленных подходов поддаётся управлению со стороны клиентов? На практике клиент не может управлять ни одним из перечисленных подходов при выборе СХД. Ситуация усугубляется тем, что фактически российские компании являются заложниками ценовой политики иностранных вендоров.

Мифы от СХД вендоров

Как правило, у потребителей фокус внимания всегда приходится на внешние маркетинговые характеристики СХД. А что если мы заглянем внутрь самого изделия? Оказывается, что там нет ничего необычного, вспоминая практику одного трёхбуквенного вендора 10 лет назад, многие СХД использовали обычный процессор Pentium III. Анализируя разработки зарубежных вендоров, аппаратная платформа СХД всегда является максимально дешёвой и простой. Существует распространённый миф о том, что для надёжного СХД решения требуется очень сложная аппаратная платформа, и именно она обеспечивает высокую надёжность. Ряд вендоров действительно проектирует сложные цифровые элементы для своих СХД, но по другим причинам, которые зачастую объясняются простой экономикой. По самым грубым подсчётам, общая стоимость «железа» в СХД не превышает 10-15 % от её фактической стоимости для конечного потребителя. Клиент платит не за аппаратную платформу, а за софт, который заставляет это железо работать.

Сейчас очень многие российские разработчики «балуются» системами на базе PCI Express, которые вот уже более 10 лет активно применяются иностранными компаниями на рынке СХД. Дело в том, что прогресс в области СХД определяется не разработкой сложных цифровых элементов, а заключается в создании простых и многофункциональных схем, где большая часть логики будет находиться на стороне программного обеспечения.

Искусство того или иного вендора в проектировании СХД как раз и заключается в создании универсальной платформы СХД (софт), которая умеет переезжать на любую аппаратную платформу с минимальными издержками.

Сейчас существует новая тенденции использования виртуализации у иностранных вендоров СХД.

Система виртуализации СХД как правило позиционируется в качестве универсальной системы доступа к любым другим СХД, которая скрывает особенности имеющегося зоопарка СХД систем у клиента и одновременно повышает производительность имеющихся СХД. Конечно стоит также отметить и «матрицу совместимости», которую выпускают СХД вендоры.

Как первая идея виртуализации СХД, так и вторая идея о матрице совместимости являются абсолютно ложными. Представим себе, как вендор СХД имеет в своём ангаре все имеющиеся на рынке СХД системы и целый штат специально обученных людей, которые проверяют каждый драйвер и каждую версию операционной системы на совместимость, аккуратно записывая результаты в матрицу. Учитывая борьбу за финансовый результат и жёсткую конкуренцию на рынке, многие вендоры просто не в силах поддерживать такие системы и вести матрицы совместимости. В итоге каждый клиент фактически на свой страх и риск применяет очередные обновления программного обеспечения.

Рассмотрим случай из практики одного клиента, который приобрёл систему виртуализации СХД.

История 2. О том как админ СХД приручал

Админ СХД Петя приступает к настройке своей новенькой виртуальной СХД, которую совсем недавно установили. Глубокая экспертиза и уверенность в своих силах позволяют Петру аккуратно настроить доступ к данным для своих серверов через новую систему виртуализации СХД. Проверяя настройки на каждом сервере, Петя убеждается, что все «пути» к дискам ведут к новой системе виртуализации СХД. Теперь все сервисы под контролем, в том числе и самые важные — электронная почта и системы обработки электронных платежей.

Приходит время интенсивной нагрузки со стороны пользователей и начинают появляться сообщения об ошибках при доступе к данным в журнале операционной системы. Долгие и мучительные переговоры с технической поддержкой показывают, что всё настроено правильно, а чтобы окончательно решить проблему с производительностью, нужно выполнить апгрейд СХД и купить ещё дополнительный объём твердотельных SSD. Такая перспектива не радует ни Петю, ни его начальника Юрия Петровича, который долго и мучительно защищал бюджет на покупку СХД. «Что же делать? — думает Юрий Петрович. — А ведь мог я взять решение от другого вендора. Оно, может, и было бы дороже, но зато могло быть надёжнее, и сейчас не случилось бы вот этих проблем».

В итоге такая история заканчивается постепенной миграцией на старое решение и отказ от новой виртуальной СХД системы. Конечно, не будем забывать, что амортизационные начисления продолжают идти в счёт новой СХД, и она висит грузом на бюджете организации.

Почему можно конкурировать с иностранными вендорами СХД?

На наш взгляд ответ очень простой — иностранные вендоры используют vendor lock-in стратегию, а следовательно любая архитектура иностранной СХД будет иметь серьёзный изъян, а значит есть ниша для замещения такой СХД. Мы в курсе всех изменений у иностранных вендоров и понимаем устройства решений от более чем 10 мировых производителей, таких как: Hitachi, DELL(EMC), HPE, Netapp и т.д.

Как можно избежать проблем при эксплуатации СХД и получить необходимый опыт программирования СХД?

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

Участники школы смогут реально научиться работать с SCSI и NVMe протоколом, узнать новые алгоритмы защиты данных и на практике попробовать эти знания в работе с системами виртуализации на базе VMWare. В ходе лабораторных работ мы расскажем о способах и принципах нагрузочного тестирования, а также об основных критериях оценки производительности СХД. Также мы уделим внимание такой проблеме как миграция данных и расскажем о бесплатных и эффективных способах миграции данных для СХД. Записаться в нашу школу может любой желающий здесь.

В следующих статьях мы расскажем про машинное обучение в СХД, а также поделимся информацией о наших новых моделях СХД.