IT для среднего и малого бизнеса

Отказоустойчивая IT-инфраструктура под нужды учетных систем класса «1С:Предприятие 8»

Данный материал является продолжением статьи «Проектирование сервера под нужды «1С:Предприятие 8» для среднего и крупного бизнеса», и агрегирует многолетний опыт в проектировании, запуске и эксплуатации отказоустойчивой IT-инфраструктуры под учетные системы на основе платформы «1С:Предприятие 8» и смежных сервисов. Основные заказчики — территориально распределенные предприятия с десятками филиалов, с сотнями рабочих мест 1С в отделениях, а также предприятия с непрерывным циклом производства. Применимо для большинства сервисов учетных, логистических систем и систем поддержки продаж, требующих высокой доступности.

 

1. Выбор архитектуры

Непрерывность vs гарантированное время восстановления

При проектировании IT-инфраструктуры под различные системы продаж, логистики, документооборота или учета важно заранее определить допустимое время простоя. Безусловно, бизнес-пользователи будут наставать на непрерывности предоставления сервиса, и базовым аргументом здесь может быть только стоимость такой непрерывности по отношению к возможным потерям, в т. ч. нефинансового характера.
В случае жестких требований непрерывности сервисов речь идет не только о размещении IT-инфраструктуры в Центрах обработки данных (ЦОД) класса TIER 3 с географическим разнесением не менее чем двух вычислительных площадок. Здесь требуется еще и соответствующая поддержка со стороны ПО, которым типовые решения на платформе «1С:Предприятие 8» не обладают.
По этой причине применительно к системам на платформе «1С:Предприятие 8» имеет смысл говорить не о непрерывности, а о времени гарантированного восстановления.
В подавляющем большинстве случаев допустимым временем простоя по критическим сервисам будет простой от 10 минут до одного часа, а по некритическим сервисам и при наличии обходного пути от двух часов до суток.
Именно исходя из таких параметров времени гарантированного восстановления мы будем проектировать систему.
В качестве основы берем платформу, допускающую синхронную или асинхронную репликацию данных на другую площадку для возможности восстановления работоспособности на другом оборудовании и в другом ЦОД.

 

Типы отказоустойчивых IT-инфраструктур традиционная, конвергентная, гиперконвергентная

В течение почти двух десятилетий («вечность», по меркам IT‑мира) для построения отказоустойчивых инфраструктур применялась традиционная архитектура с наличием вычислительных узлов на той или иной платформе и внешнего отказоустойчивого хранилища (СХД) с файловым или блочным доступом. При этом СХД являлось абсолютно независимым устройством, с набором физических интерфейсов для взаимодействия с вычислительным узлами, своей встроенной ОС, набором пользовательских интерфейсов управления, сервисными контрактами. Примером многолетнего успеха на рынке СХД очень долгое время была контролировавшая весомую долю рынка компания EMC2, для которой производство СХД было основным бизнесом.
Преимущества такого подхода для конечного корпоративного потребителя, купившего СХД и подписавшего сервисный контракт, были очевидны:
 - есть СХД, за работоспособность которого отвечает по контракту поставщик;
 - за сохранность данных на СХД также вроде как отвечает поставщик;
 - это отдельное законченное решение с набором характеристик, которое «просто работает».
И это действительно удобно, когда тебе в ЦОД доставляют новый диск с просьбой заменить «подозрительный» в СХД до того, как ты узнал, что у СХД возможны проблемы с каким-либо диском (не говоря уже о каких-то вопросах с сохранностью данных!).
К условным недостаткам такого подхода можно отнести:
 - стоимость покупки и поддержки решения;
 - масштабируемость в устройствах младшего и среднего уровней ограничена;
 - возможность модернизации также очень часто ограничена (в первую очередь аппаратной платформой).
Как ни странно, такая архитектура для хранилищ малого и среднего класса достаточно затратна и для самого производителя СХД, т. к. вынуждает поддерживать и аппаратную, и программную часть.
Вычислительные же узлы могли быть либо от стороннего производителя, либо поставляться тем же поставщиком, что и СХД такие полные комплекты традиционно предлагали HP, IBM и другие.

https://upload.wikimedia.org/wikipedia/commons/6/63/2nodeHAcluster.png

Рис. 1 Общая схема отказоустойчивого кластера.

Сдвиг тектонических плит на рынке СХД и, соответственно, рынке создания отказоустойчивых IT-инфраструктур вызвало появление программно-определяемых СХД  (Software-Defined Storage, SDS). В немалой степени распространению таких систем поспособствовало появление файловой системы ZFS, на основе которой появилась целая плеяда продуктов и решений, в т. ч. таких как Nexenta или Open-E Jovian. Для рынка же продуктов «1С:Предприятие» принципиальным стал выход Windows Server 2012 в ее состав вошел компонент Windows Storage Spaces, который вместе с функциями кластеризации от Microsoft Hyper-V Cluster позволил создавать недорогие и очень эффективные SDS.

Software-Defined Storage, построенные на основании Windows Storage Spaces, могут относится к конвергентным решениям, так и к гиперконвергентным.
В конвергентных решениях и за среду исполнения, и за среду хранения отвечает одна и та же ОС, при этом функции хранения и исполнения приложений физически распределены на различные устройства. Классическим примером именно конвергентного решения на Windows Storage Spaces является продукт Windows Storage Server, предназначенный исключительно для поддержания функций хранилища. Преимущества такого подхода в разделении слоев хранения и исполнения, и как следствие возможность наращивать их ресурсы независимо друг от друга. Именно такая схема изначально использовалась в Microsoft Azure.
В гиперконвергентных средах функции хранения и исполнения приложений совмещаются на одних и тех же устройствах. К примеру, Microsoft Hyper-V Cluster в Windows Server 2012 позволяет одновременно восьми вычислительным узлам, объединённым в кластер, совместно работать с общим централизованным дисковым пространством Cluster Shared Volume, подключенным к ним напрямую посредством SAS SAN. Соответственно все восемь узлов кластера могут выполнять как функции хранения данных, так и функции их обработки. Аналогичная идея заложена и в VMware vSAN, где каждый из узлов (не менее трех) выполняет как функции распределенного хранилища, так и функции вычислительного узла. 

2. Система хранения данных (СХД) что выбрать?

Основой любой отказоустойчивой IT-инфраструктуры всегда является та или иная система хранения данных (СХД), призванная обеспечить необходимый уровень сохранности, доступности данных с требуемой производительностью.
Мы рассмотрим СХД для нужд учетных и иных систем на платформе «1С:Предприятие 8» не с точки зрения готовых продуктов, а с точки зрения различных технологий построения СХД, сильных и слабых сторон конкретных решений и их оптимизации по производительности и стоимости.

Централизованные и распределенные среды хранения, их особенности.
Отказоустойчивые системы хранения данных (СХД) для бизнес-приложений можно разделить на два базовых класса централизованные и распределенные. Безусловно, любое централизованное хранилище путем настройки репликации можно легко превратить в распределенное, но в данном случае подразумевается именно базовая основа СХД.
Хорошими примерами централизованной и распределенной сред хранения являются два продукта Microsoft Storage Spaces и Storage Spaces Direct.

Централизованная среда хранения Microsoft Storage Spaces является встроенным сервисом Windows Server 2012. В ней применяются общие хранилища данных, к которым обеспечивается одновременный доступ к CSV-томам с нескольких физических узлов посредством SAS SAN. Физически такое хранилище реализуется на базе одного или нескольких внешних 2-контроллерных SAS JBOD, устройства хранения HDD и SSD с интересом SAS (т. е. два порта ввода/вывода на каждом), средства коммутации SAS SAN и SAS HBA.

http://www.tech-coffee.net/wp-content/uploads/2015/06/060815_1004_ImplementSt2.jpg

Рис. 2.  Централизованное хранение данных с общим доступом посредством Shared SAS

На рис. 2 показано, что два и более (до восьми) физических узлов с запущенным на них сервисом Scale-Out File Server посредством коммутируемой сети хранения SAS SAN получают доступ к данным на устройствах хранения SAS SSD и SAS HDD, размещенных в SAS JBOD. При этом арбитраж доступа к данным реализуется на уровне программного слоя Microsoft Storage Spaces и Microsoft Hyper-V Cluster. Доступ на запись к конкретному файлу одновременно имеет только один из узлов, а вот читать могут одновременно несколько узлов. В случае выхода из строя любого из узлов Scale-Out File Server Cluster происходит лишь незначительная задержка в передаче данных без обрыва соединения, пока поток чтения/записи переключается на другой узел (при использовании протокола SMB3). Доступ приложений к хранимым данным осуществляется либо непосредственно с узлов в кластере хранения по протоколу SAS, либо через сеть Ethernet 1/10/25/40/100 Gb.
Архитектура централизованного хранилища обеспечивает минимальные издержки:
 -  в латентности на запись записи данных (т. к. нет операций репликации на другие узлы),
 -  в латентности на чтение данных (все узлы имеют одинаковый доступ к данным),
 -  в затратах «сырой» емкости средств хранения (хранится одна копия данных),
 - относительно невысокая цена, т. к. Storage Spaces входит в Windows Server Standard.
К ее относительным минусам можно отнести:
 - использование внешних SAS JBOD (как отдельных устройств),
 - при наличии более чем двух узлов для обеспечения отказоустойчивости необходимы SAS Switch,
 - использование только SAS SSD/HDD,
 - несколько более сложное масштабирование (по емкости и по производительности раздельно).

Распределенная среда хранения от Microsoft, Storage Spaces Direct, появилась в Windows Server 2016. В ней данные хранятся локально, на каждом узле хранения, используя внутренние диски сервера либо внешние диски прямого подключения (к примеру, доступные по той же SAS SAN и находящиеся во внешних SAS JBOD, но разделенные с помощью зонирования). При этом могут использоваться в том числе диски с интерфейсом SATA и NVMe, а не только SAS.

http://www.tech-coffee.net/wp-content/uploads/2015/06/060815_1004_ImplementSt3.jpg

Рис. 3.  Распределенное хранение данных.

На рис. 3 показан распределенный кластер хранения, обеспечивающий отказоустойчивость в Microsoft Storage Spaces Direct, который состоит минимум из двух физических узлов с запущенным на них сервисом Scale-Out File Server. Диски на узлах хранения могут быть как внутренними с протоколами SATA, SAS, NVMe, так и внешними в SAS JBOD. Для эффективной репликации данных на другие узлы необходимо между всеми узлами хранилища иметь сеть не хуже 10Gb Ethernet, желательно с поддержкой технологии RDMA. Точно так же, как и в варианте централизованного хранения, в случае выхода из строя любого из узлов Scale-Out File Server Cluster происходит лишь незначительная задержка в передаче данных без обрыва соединения, пока поток чтения/записи переключается на другой узел хранения (при использовании протокола SMB3). Доступ приложений к хранимым данным осуществляется либо непосредственно с узлов в кластере хранения как локальным ресурсам, либо через сеть Ethernet 1/10/25/40/100 Gb.

Для правильного выбора типа хранилища, распределенного или централизованного, необходимо остановиться на особенностях работы любых распределенных хранилищ данных и связанных с ними накладных расходах.
По сути, в минимальном виде мы имеем структуру хранения с двумя узлами, как на рис. 3.


two-way-mirror
Рис. 4 – минимальное распределенное хранилище данных.

Эта архитектура легко масштабируется, как показано на рис. 5

three-way-mirror
Рис. 5 – расширение распределенного хранилища данных.

И так далее, по мере добавления узлов хранения.
При этом используется метод синхронной репликации данных, хорошо проиллюстрированный на странице Storage Replica Overview:

https://i-technet.sec.s-msft.com/ru-ru/windows-server-docs/storage/storage-replica/media/storage-replica-overview/storage_sr_synchronousv2.png

Рис. 6 – Принцип работы синхронной репликации.

Другими словами, в процессе записи данных на распределенное хранилище выполняются следующие шаги:

1. Приложение записывает данные на узел хранилища.
2. Данные записываются в Журнал на Сайте_1 и одновременно реплицируются на удаленный Сайт_2.
3. Данные записываются в Журнал на удаленном Сайте_2.
4. Отправляется подтверждение от удаленного Сайта_2 на Сайт_1 о записи копии в Журнал.
5. Подтверждение операции записи Приложению.
6. Данные записываются в том хранения как «отложенная запись», в то время как для Журналов применяется только прямая запись.

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

Очевидно, что схема с репликацией в распределенном хранилище имеет большее количество шагов для завершения транзакции, чем в централизованном хранилище, где запись производится сразу в одно место, а значит, и время выполнения такой транзакции при прочих равных условиях будет больше.
Архитектура распределенного хранилища обеспечивает преимущества:
 - возможность использования сверхскоростных NVMe SSD,
 - возможность использования SATA SSD (как правило дешевле SATA SSD),
 - не требует отдельно SAS SAN (дополнительные компоненты и их обслуживание),
 - проще масштабируется простым добавлением узлов.
Из моментов, на которые необходимо обратить внимание:
 - помнить, что с высокой вероятностью латентность на запись у распределенной системы будет выше, чем у централизованной (важно для транзакционных баз данных, OLTP),
 - обязательно необходима очень быстрая межузловая сеть 10/40/100Gb Ethernet, желательно с поддержкой RDMA,
 - в случае применения любых HDD и SSD для дисков кеша (а это минимум два диска) крайне желательно использовать диски NVMe SSD, т.к . на них автоматически размещается транзакционный диск Журнала.
По большей части это явно прописано на странице Storage Spaces Direct hardware requirements и Planning volumes in Storage Spaces Direct.
Из условных «недостатков» современных гиперконвергентных решений можно выделить ключевой это цена, порядка $6000 за узел. Microsoft Storage Spaces Direct присутствует только в версии Windows Server Datacenter, который придется купить на два узла. Приблизительно в такую же сумму за каждый узел обойдется и решение VMware vSAN плюс плата за объем хранения, минимальный комплект требует трех узлов.

Описанное выше актуально не только для систем на базе технологии Microsoft Storage Space, но и для систем класса Software Define Storage от других производителей. В качестве систем с централизованным хранением можно рассматривать RAIDIX или Open-E Jovian DSS. Распределенные системы — VMware vSAN, EMC Scale IO, Datacore SANsymphony.

Remote Direct Memory Access

Важную роль в современных распределенных средах выполняют сетевые адаптеры. И требование поддержки RDMA (Remote Direct Memory Access) у Microsoft Storage Spaces Direct отнюдь не случайно.
Непрерывная борьба с задержками сетевого обмена между серверами привела к появлению протокол InfiniBand, в котором благодаря использованию технологии RDMA удалось минимизировать участие процессора в операциях копировании данных в/из оперативной памяти. Infiniband и сейчас интенсивно применяется в крупных дата-центрах, в т. ч. есть он и в одном из сегментов Microsoft Azure.
Задействование же технологии RDMA среде Ethernet поверх транспортного слоя TCP/IP позволила получить низкую латентность доступа к данным, высокую производительность обмена и умеренную стоимость благодаря использованию стандартных компонент. Именно на высокоскоростных интерфейсах Ethernet с поддержкой RDMA построена большая часть Microsoft Azure
В системах с централизованным  хранением данных за латентность дисковой подсистемы, кроме самих дисков, отвечает SAS SAN. В распределенных системах хранения за латентность, особенно в режиме записи, в т. ч. отвечает и сетевой компонент, InfiniBand или Ethernet. Пока отклик дисков был медленным — сети не были узким местом. С появлением твердотельных накопителей SSD, а в особенности таких, как Intel Optane Technology (в прошлом 3D XPoint), стирающих грани между оперативной и внешней памятью, требования к пропускной способности и латентности сетевых интерфейсов резко возросли. Современная сетевая архитектура, применяемая для межузловых соединений в кластере, требует широкополосных неблокируемых каналов с низкими задержками и минимизации участия CPU в обслуживания транзитных операций.


От классических «аппаратных» СХД к Software Define Storage

Что из себя представляют классические «аппаратные» СХД от Brand Name?
Слегка утрируя  это тот же набор «железа», что доступен и в канальном варианте, но в проприетарном исполнении. С какой-то проприетарной прослойкой софта в дополнение к традиционным ОС и программным модулям. А для внешнего потребителя он выглядит как «Black Box» с набором «движков-регуляторов».
Хорошим примером тут является та же Nexenta, не скрывающая своего происхождения от OpenSolaris, Ubuntu и ZFS.
Можно ли получить сходные по параметрам производительности и отказоустойчивости продукт на основании канальных продуктов на уровне «железа» и «софта»?
Для начала посмотрим, как устроена типовая отказоустойчивая 2-контроллерная СХД.

 

Подкоп Microsoft под рынок систем хранения данных

Рис. 7 – Схема двухконтроллерной отказоустойчивой СХД с расширением с помощью JBOD.

На рис. 7 схематически представлена отказоустойчивая СХД, состоящая из 2-контроллерной «головы» (Front End контроллеры FC, SAS, iSCSI, синхронизируемый кеш + логика, Back End контроллер FC или SAS), в которой сосредоточены все вычислительные ресурсы и управление, и дисковых полок, часто представляющих из себя вариации на тему SAS или FC JBOD.
По своей сути «голова» мало чем отличается от двух совершенно отдельных серверов, собранных в общем корпусе, как представлено на рис. 8, за исключением синхронизации кеша двух контроллеров.

Подкоп Microsoft под рынок систем хранения данных

Рис. 8 – Схема отказоустойчивой СХД на базе двух серверов в одном корпусе в кластере  + JBOD.

Если взять типовую серверную платформу, совмещающую в одном корпусе два серверных узла, например 1U Twin Solutions с установленными в двух портах SAS HBA, добавить SAS JBOD и проинсталлировать на них Open-E Jovian DSS (основан на ZFS), то по техническим характеристикам мы получим продукт, вполне сравнимый с тем же Nexenta (сервис пока не обсуждаем).

В таком случае что мешает пойти дальше и взять две абсолютно типовые серверные платформы 1U Intel® Server System с SAS HBA и подключить к ним всё те же SAS JBOD из серии Intel® Storage Systems JBOD2000 Family, как показано на рис. 9, добавить выбранное ПО для СХД и получить собственную отказоустойчивую СХД в формате кластера серверов с JBOD?

Рис. 9 – Схема отказоустойчивой СХД на базе двух серверов в кластере + JBOD.

Аналогичный путь получения централизованного отказоустойчивого хранилища данных нам предлагают и компания Microsoft с технологией Storage Spaces, и имеющая родственные связи с Intel польско-немецкая компания Open-E с продуктом Jovian DSS, и компания RAIDIX из Санкт-Петербурга.
Еще более показательной была позиция компании EMC2, являющейся одним из крупнейших поставщиков дисковых массивов, ныне поглощенной Dell. У нее есть сразу два продукта, ориентированных на рынок SDS,  VMware VSAN, EMC Scale IO.

Так почему сразу столько игроков двинулись в сторону DSS?
Давайте просто перечислим преимущества SDS перед традиционными аппаратными СХД:
 - объединение вычислительных ресурсов и ресурсов хранения в едином конвергентном решении;
 - реализация СХД серверами и JBOD стандартной компоновки («с полки»);
 - производительность и емкость масштабируются добавлением новых блоков, без внесения изменений в логику управления СХД;
 - ПО и «железо» обновляются независимо друг от друга, каждый в своем жизненном цикле.

Вполне вероятно, что многие компании предпочтут традиционно использовать готовые продукт и сервисы с годовой подпиской (если это будет возможно). С другой стороны, использование SDS в различных учтенных системах на платформе «1С:Предприятие 8» позволяет добиться значительно лучшего «попадания» дисковой подсистемы «под задачу», да еще и с гораздо меньшими затратами (в чем легко убедиться, сравнив, к примеру, стоимость канального SAS SSD HGST 2 TB с аналогичным по характеристикам SSD для проприетарных СХД).

 

3. Практика построения отказоустойчивых решений

После теоретической части перейдем к практике. Для тех, кто выбирает путь использования классических СХД, необходимо детально изучить возможности данной СХД и желательно совместно с поставщиком оптимизировать под ваши задачи. При этом описанные ниже моменты по дисковой и иной оптимизации будут вполне применимы и к готовым СХД.
С методами измерения потребностей в ресурсах, а также ориентировочного расчета требований к вычислительным узлам и дисковым пространствам рекомендуется ознакомиться в материале «Проектирование сервера под нужды «1С:Предприятие 8» для среднего и крупного бизнеса».
Мы же подробно разберем построением кластера с использованием СХД на базе SDS.

Гиперконвергентное решение на централизованной архитектуре хранения с Microsoft Storage Spaces

Это один из самых простых и наименее затратных путей построить «стартовый» отказоустойчивый кластер с использованием технологий Microsoft.
Для этого нам понадобиться относительно простой набор типовых, канальных продуктов (а значит легко взаимозаменяемых):
1. Вычислительные узлы в формате 1- или 2-процессорных серверов
2. Установленные в каждом из серверов 2-канальные SAS HBA
3. 2-контроллерный SAS JBOD
4. Минимум 3 шт. SAS SSD (и NL SAS HDD по потребности)
5. 4 шт. 4-канальных SAS-кабеля для внешнего подключения (для прямого дублированного подключения вычислительных узлов к SAS JBOD).
Результат на рис. 10.

WS-2012R2-cluster.jpg

Рис. 10 – Схема отказоустойчивого кластера с централизованным хранением.

В данном решении каждый из вычислительных узлов подключен к двум различным контроллерам SAS в JBOD. В свою очередь каждый диск с интерфейсом SAS (и SSD, и HDD) также имеет два порта, и в свою очередь подключен к двум контроллерам JBOD одновременно. Питание у SAS JBOD и в вычислительных узлах также дублировано. Таким образом, этот состоящий из трех компонент кластер способен обеспечить отказоустойчивый доступ к любым данным, хранимым на его дисках.
Диски. Минимальный набор для создания кластерного тома CSV три физических устройства хранения. Идеальный вариант для всех типов данных «1С:Предприятие 8» это All Flash массив, т. е. исключительно SAS SSD. Для не очень нагруженных ситуаций, когда производительности SSD на запись в IOPS вполне достаточно,  можно на томе из четырех SAS SSD разместить и DB, и tempDB. С ростом нагрузки (а это можно легко отследить с помощью PerfMon) рекомендуется вынести tempDB на отдельный том (а это как минимум еще три-четыре SAS SSD). Данные же SQL log рекомендуется (в целях безопасности хранения) сразу же вынести на отдельный от DB том. Том под SQL log также может быть собран на трех-четырех SAS SSD, ну или можно построить том с 2-уровневым хранением на двух SAS SSD + 4 NL SAS HDD тогда на этом томе вполне можно разместить backup.
SAS JBOD. Исходя из задачи хранения данных, учтенных в системе на платформе «1С:Предприятие 8», и наличия в продаже SAS SSD емкостью в 2TB, именно под задачи 1С наверняка будет достаточно даже небольшого Intel Storage System JBOD2224S2DP на 24 отсека для дисков 2.5" или его аналогов. Ключевым здесь является наличие двух SAS-expanders.
Вычислительные узлы (серверы). Как показала практика, весьма эффективной стратегией является размещение на узлах кластера в т. ч. и вычислительных задач, а не только задач обслуживания хранилища. Дело в том, что задачи обслуживания хранилища требуют относительно немного ресурсов, 2-процессорные вычислительные узлы в кластере с использованием многоядерных (10 ядер и более) CPU вполне комфортно размещаются и MS SQL Server (как правило ставится в основную ОС «на железо»), и отдельной VM c «1С:Предприятие 8». Сервер приложений, и сервер Remote Desktop (также в отдельной VM).
Важной рекомендацией для сред «1С:Предприятие 8» остается использование именно высокочастотных серверных процессоров (при условии верного расчета необходимого количества ядер CPU). Также для гиперконвергентных решений рационально использовать CPU с большим количеством ядер.
Масштабируемость. При правильном подборе компонент вычислительных узлов такой кластер может обслуживать сотни и тысячи одновременных пользователей 1С как в одной, так и в нескольких базах данных. В случае нехватки вычислительных ресурсов добавляются 2 шт. SAS Switch и далее наращивается до восьми вычислительных узлов с прямым подключением данным по SAS SAN. При потребности в новых емкостях добавляются SAS JBOD. Либо же добавляются/меняются диски в JBOD. В итоге получается легко масштабируемая IT-инфраструктура, как на рис. 11.

 

 

  Рис. 11 – Масштабируемая архитектура централизованного хранилища на Microsoft Storage Spaces.

Такой алгоритм уже проверен годами практики и зарекомендовал себя как вполне надежное, скоростное и ценоэффективное решение.
К любому из узлов кластера, подключенного к SAS SAN, можно по сети 10/25/40/100 Gb Ethernet подключать другие вычислительные узлы, далее масштабируя кластер по производительности, как показано на рис. 11, перейдя от гиперконвергентной к просто конвергентной инфраструктуре.

Architecture using Storage Spaces with shared SAS  

  Рис. 12 – Конвергентная архитектура централизованного хранилища на Microsoft Storage Spaces.

 

Гиперконвергентное решение на распределенной структурой хранения на Microsoft Storage Spaces Direct или VMware VSAN

Распределенная архитектура хранения и в реализации Microsoft Storage Spaces Direct, и в реализации VMware VSAN позволяет строить гиперконвергентые (каждый узел кластера совмещает функции вычислений и хранения данных) решения.

Гиперконвергентные локальные дисковые пространства

  Рис. 13 – Гиперконвергентная архитектура распределенного хранилища.

В таком решении каждый из вычислительных узлов связан с соседним скоростной сетью 10 Gb Ethernet и выше, желательно с поддержкой RDMA. Таким образом, состоящий из двух или более компонент кластер способен обеспечить отказоустойчивый доступ к любым данным, хранимым на его дисках.
Диски. Минимальный набор для создания кластерного тома CSV — 4 физических устройства хранения. Идеальный вариант для всех типов данных «1С:Предприятие 8» это массив на четырех NVMe SSD. Для не очень нагруженных ситуаций, можно собрать том из четырех SATA SSD + двух NVMe SSD для кеша и журнала. Данные SQL log рекомендуется (в целях безопасности хранения) сразу же вынести на отдельный от DB том, который может быть собран на четырех NVMe SSD, либо же на двух NVMe SSD + 4 NL SAS HDD тогда на этом томе можно разместить backup.
Ethernet. Для эффективной работы распределенной системы хранения абсолютно необходима быстрая сеть Ethernet на скоростях 10/25/40/100 Gb. Также желательно обеспечить минимальную латентность сети, что достигается применением технологии RDMA для Ethernet (исходя из рекомендаций Microsoft).
Вычислительные узлы (серверы). Исходя из опыта эксплуатации VMware VSAN (по Microsoft Storage Spaces Direct на момент подготовки материала опыт минимален), также самой эффективной стратегией является размещение на узлах кластера в т. ч. и вычислительных задач, а не только задач обслуживания хранилища. 2-процессорные вычислительные узлы в кластере с использованием многоядерных (10 ядер и более) CPU позволяют запускать на узлах и в отдельных VM и MS SQL Server, и  «1С:Предприятие 8». Сервер приложений, и сервер Remote Desktop.
Масштабируемость. При грамотном подборе компонент узлов кластера ограничения масштабирования будут связаны скорее с возможностями самой «1С:Предприятие 8». В случае нехватки вычислительных ресурсов добавляются узлы хранения/вычисления. Либо осуществляется переход к конвергентному решению с разделением узлов хранения и вычислительных узлов, как на рис. 14.

Конвергентные локальные дисковые пространства

  Рис. 14 – Конвергентная архитектура распределенного хранилища.

4. Применение различных типов дисков в распределенных средах хранения

На время написания данного материала наиболее перспективным направлением развития масштабируемых отказоустойчивых IT-инфраструктур выглядит построение гиперконвергентных сред с распределенным хранением данных. Они легко масштабируются, могут быть набраны типовыми «строительными блоками» узлами, а сами узлы могут быть оптимизированы под конкретный круг задач (и таких типов узлов может быть несколько). Как пример готовых решений, “заточенных“ производителем именно для гиперконвергентных сред, можно рассматривать оборудование серии Intel Data Center Blocks for Cloud уже сертифицированными VMware Cloud Block VSAN Ready Node (а для VSAN это имеет огромное значение!) или Cloud Blocks for Microsoft. Сервисное обслуживание и модернизация и «железа», и ПО в такой архитектуре разделено и таким образом заметно упрощается. А чем больший по размерам ДатаЦентр создается, тем выше эффект от использования типовых блоков/решений будет получен.
Для распределенных хранилищ, а в особенности для гиперконвергентных сред, весомое значение имеет тип применяемых дисков. В централизованном хранилище под Microsoft Storage Spaces мы жестко ограничены интерфейсом SAS и SAS SAN. В распределенных же Microsoft Storage Spaces Direct или VMware VSAN мы имеем все шансы повысить производительность за счет применения NVMe SSD, а в дальнейшем и Optane SSD. Ведь один из аргументов в пользу именно распределенных архитектур хранения возможность использования локальных хранилищ, в т. ч. скоростными SSD с интерфейсом NVMe и недорогими SSD с интерфейсом SATA.

NVMe SSD U.2. Стандартизированное решение от Intel с нативной поддержкой NVMe SSD в формате 2,5” c HotSwap пока недоступно. Оно ожидается в виде платформы под процессоры Intel Xeon E5 поколения v5, которые будут спроектированы для прямого подключения восьми дисков U.2. В то же время сервера с разъемом SFF-863, получившие название U.2 (рис. 15), позволяющий подключать в него устройства SAST, SAS и NVMe, уже появляются. К примеру, их можно реализовать для платформ Intel с помощью 1U Hot-swap Backplane Upgrade Kit with 4x NVMe SSD Support или 2U Hot-swap Drive Cage Upgrade Kit with 4x NVMe SSD Support, что уже сейчас позволяет подключить до четырех 2,5” HotSwap NVMe SSD для каждого из узлов.
 

Перспективы U.2 в серверах

  Рис. 15 – Разъемы SAS и U.2.

С учетом размещения на лицевой панели сервер 1U до 10 HotSwap отсеков 2,5”, из которых два или четыре могут быть NVMe SSD Intel SSD DC D3700, а остальные шесть-восемь отсеков можно заполнить Read-Intensive SATA SSD Intel SSD DC S3610, дополнив 14-16 Core CPU Intel Xeon E5  и соответствующим объемом RAM можно получить просто великолепную All Flash гиперконвергентный узел хранения/вычислений для нужд «1С:Предприятие 8».

Масштабируемость U.2. Важным преимуществом использования именно U.2 по сравнению с подключением NVMe диска непосредственно в шину PCIe на материнской плате как раз является поддержка «горячей замены» диска без остановки сервера, что важно в первую очередь для гиперконвергентных систем. Коннектор U.2 снимает и вопрос нехватки слотов расширения PCIe — в 1U-корпус можно поставить 8-10 фронтальных дисков SFF, в 2U — до 24. Так как каждый процессор Intel Xeon E5 поддерживает по 40 линий PCIe, а одному NVMe SSD достаточно четырех, то все 24 диска U.2 можно подключить напрямую, и еще останется резерв для других интерфейсов. А вот с картами под разъём PCIe столько дисков подключить не получится.
В U.2 также реализовано двухпортовое подключение, когда накопители используют два канала PCIe х2 вместо одного PCIe х4, что потенциально позволит в будущем создавать отказоустойчивые системы на дублированной шине PCIe. Примерами таких устройств служат Intel SSD DC D3700 and D3600 Series и HGST ULtrastar SN200.

Производительность дисков с интерфейсами SATA, SAS и NVMe
Зачем в материале уделено много внимания технологии NVMe? Ответ на это вопрос можно получить из результатов тестов, которые демонстрируют производительность устройств с различным интерфейсом и под различными нагрузками. Для тестирования использовался IOMeter. Применялось по два диска близких по параметрам и емкости, но с различными интерфейсами. В программном “mirror” под Microsoft Storage Spaces.
Приведенные ниже графики в первую очередь позволяют понять тенденцию, и в зависимости от целевого использования выбрать тот или иной диск. Использовались SSD диски NVMe U.2 HGST Ultrastar SN100, SAS HGST Ultrastar SSD1600MM, SATA Intel S3710.

Тест «Базы данных». Для начала давайте посмотрим, как ведут себя все три интерфейса в тесте «База данных» (70% Read / 30% Write) на самом распространенном блоке 4KB с ростом длины очереди запросов (рис. 16).

 

  Рис. 16 – Тест «Базы данных», блок 4KB, очередь от 1 до 128 .

Хорошо видно, что уж на очереди 32 диск с интерфейсом SATA по сути выходит на насыщение и далее работает с максимальной производительность на уровне 85-90 KIOPs. Диск с интерфейсом SAS (SAS-3, 12 Gb/s) выходит на насыщение также на очереди в 32, но демострирует гораздо лучшую производительность более 125 KIOPs. А диск NVMe даже на очереди 128 продолжает рост производительности, перепрыгнув за 200 KIOPs.
Еще более яркий отрыв от конкурентов NVMe диск демонстрирует на том же тесте, но с блоком 8KB (рис. 17).

  Рис. 17 – Тест «Базы данных», блок 4KB, очередь от 1 до 128 .

Тест «Произвольное чтение». Не менее показателен и тест с произвольным чтением (рис. 18) дисков с различным типом интерфейса блоками по 4KB, 8KB и 64KB (типичный блок для MS SQL Server).

  Рис. 18 – Тест «Произвольное чтение», блоки 4KB, 8KB и 64KB, очередь от 1 до 128 .

Диск с интерфейсом NVMe под нагрузкой демонстрирует превосходство над диском с SATA интерфейсом на блоке 4KB до 5 раз, на блоке 8KB до 5,5 раз, и на блоке 64KB также около 5 раз. При этом надо обратить внимание, что на малых нагрузках, с очередью до 8,  разница отнюдь не так высока и измеряется в процентах, а не в разах.

Тест «Произвольная запись». Далее посмотрим на тест «Произвольная запись» (рис. 19) блоками по 4KBи 64KB.

  Рис. 19 – Тест «Произвольная запись», блоки 4KB, 8KB и 64KB, очередь от 1 до 128 .

Здесь превосходство диска с интерфейсом NVNe над диском с интерфейсом SATA не столь огромно, как в операциях произвольного чтения, но все равно разница почти двухкратная (на очередях более 2).

Тест «VDI». Далее посмотрим, как ведут себя диски на тесте «VDI», который характеризуется высокой нагрузкой на запись (20% Read / 80% Write).

  Рис. 20 – Тест «VDI», очередь от 1 до 128, IOPS .

Как хорошо видно, при низких нагрузках (очередь до 4) принципиальной разницы у дисков с разным интерфейсом нет, а вот с ростом нагрузки до очереди 128 диск NVMe уходит в отрыв, обходя диск SATA на 200%, а диск SAS почти на 100%.

А что при этом происходит с латентностью доступа к диску (рис. 21)? 

  Рис. 21 – Тест «VDI», очередь от 1 до 128, латентность.

Собственно говоря, видим ту же картинку  при низких нагрузках (очередь до 4) принципиальной разницы у дисков с разным интерфейсом нет, а с ростом нагрузки до очереди 128 диск NVMe уходит в отрыв, показывая более низкие значения относительно диска SATA почти на 200%, а относительно диска SAS почти на 80%.

Утилизация CPU
И завершающий график утилизация CPU дисками с различным интерфейсом во всё том же тесте «VDI» (рис. 22).

  Рис. 21 – Тест «VDI», очередь от 1 до 128, латентность.

Как легко заметить, чуда не произошло. Разница в производительности между дисками с интерфейсом NVMe и SATA в близкой пропорции отражается на процентах утилизации CPU. И если SATA диски при очереди в 128 демонстрируют утилизацию CPU на уровне 12-15%, то NVMe диски утилизируют уже 45% процессорной производительности. И это в 2-процессорном сервере с CPU Intel Xeon 14-core E5-2690 v4 (2600/35M). Другими словами, по сути операции ввода-вывода на NVMe SSD утилизируют ресурсы 12 из имеющихся 28 ядер в системе! А ведь есть еще и скоростные Ethernet 10/25/40/100 Gigabit адаптеры в системе, также требующие немалого ресурса CPU…

Таким образом, можно сделать два ключевых вывода:
 - При малых нагрузках существенной разницы между дисками с интерфейсами SATA и NVMe нет, но при этом NVMe немного быстрее. Таким образом для задач не слишком интенсивных, таких как MS SQL Log, вполне достаточно и SATA SSD (если нет свободных портов для установки NVMe).
 - При больших нагрузках диски NVMe демонстрируют 25-кратное превосходство над дисками с интерфейсом SATA, но при этом создают очень существенную нагрузку за CPU. Значит, для задач с высокой нагрузкой (DB, tempDB) предпочтение имеет смысл отдавать дискам с интерфейсом NVMe, и на узлы с такими дисками выбирать многоядерные процессоры Intel Xeon из верхнего сегмента.
Отдельно надо отметить, что существенной разницы в цене между дисками одного класса с интерфейсами SATA и NVMe нет. Выбор имеет смысл делать исходя именно из технологических соображений.

5. Полезные технологии

SQL Server AlwaysOn  
SQL Server AlwaysOn это подтип распределенной структуры хранения данных, реализуемый не на уровне кластеризации вычислительных узлов для создания общего пространства хранения, а на базе дискретных серверов и возможностей MS SQL Server. Каждый набор баз данных доступности размещается на своем отдельном узле. Существует два типа реплик доступности: одна первичная реплика, которая содержит основные базы данных (доступна на запись и чтение) и до восьми вторичных реплик (обычно доступных на чтение).
Данная технология весьма интересна в ракурсе обеспечения непрерывности сервиса, но крайне редко применяется вместе с «1С:Предприятие 8».
Зато подобная технология может быть эффективно применена для аналитических баз данных OLAP на основе MS SQL Server, создаваемых на основании OLTP данных из «1С:Предприятие 8». Каждая аналитическая задача по сути может работать в режиме онлайн со своей копией данных, данными для отчетности или отчетностью, и при этом не создавая нагрузки на основную рабочую систему. Такая архитектура применяется в крупных организациях, розничных сетях (например, для онлайн-определения, какой товар необходимо подвезти в торговый зал).

Репликация и облачные сервисы для резервной площадки
Самой большой ценностью в учетных системах, как правило, являются сами данные.
Но и полностью настроенная IT-инфраструктура также является немалой ценностью.
Многие крупные предприятия с целью минимизации вероятности простоя более допустимого времени применяют технологию синхронной (если позволяют каналы) или асинхронной репликации и таблиц SQL Server, и всей инфраструктуры.
Если позволяют финансовые ресурсы или если это требования безопасности реплика делается в свой выделенный ДатаЦентр или арендованный блок в общественном ДатаЦентре.
Если нет жестких требований по безопасности, вполне оправданным является стратегия аренды у облачного провайдера как минимум одного узла и емкостей в хранилище для размещения полной реплики данных вне переделов основной вычислительной площадки. Кроме собственно ресурсов для поддержания реплики хранилища желательно заключить с сервис-провайдером контракт о предоставлении по запросу вычислительных ресурсов, необходимых для развертывания резервной IT-инфраструктуры из реплики. И таким образом получить эконом-вариант геораспределенной IT-инфраструктуры.
Минимальным же уровнем для отказоустойчивой инфраструктуры является ежедневный backup всей инфраструктуры и данных с глубиной не менее чем за три дня, размещенный вне пределов основной вычислительной площадки.

Заключение

При проектировании отказоустойчивой IT-инфраструктуры для нужд систем на базе платформы «1С:Педприятие 8» в первую очередь имеет смысл определиться с типом и архитектурой СХД и всей системы в целом.
Выбор готовой отказоустойчивой СХД необходимо делать с учетом ее особенностей и соответствия задачам именно поддержки работы нагруженных транзакционных баз данных.
При принятии решения строить конвергентную или гиперконвергентную отказоустойчивую инфраструктуру необходимо вначале определиться со средой виртуализации и хранения, а затем уже выбирать оборудование, сверяясь с листами валидации производителя ПО.
Построения собственной отказоустойчивой СХД на основе технологий Software Define Storage не является чем-то невероятно сложным. Зато позволяет оптимизировать систему именно под нужды своих прикладных задач, причем зачастую заметно дешевле в развертывании и поддержке.
При прочих равных условиях гиперконвергентные решения как на основе централизованного хранилища, так и на базе распределенного хранилища демонстрируют хорошие показатели цены и производительности.
Ввиду ценовой политики вендоров ПО на момент написания статьи наименьшую цену входа в отказоустойчивую гиперконвергентную IT-инфраструктуру дает решение на основе централизованного хранилища на Windows Storage Spaces.
Для гиперконвергентных решений с распределенным хранением данных оптимальным является использование многоядерных CPU из старшего сегмента Intel Xeon 14-core E5-2690 и выше, высокопроизводительных дисков NVMe SSD класса Intel SSD DC D3700, а также скоростных сетевых адаптеров Ethernet 10/40 Gigabit с поддержкой RDMA и аппаратными средствами оптимизации производительности в виртуальной среде, такими как Intel VT-c.