Большой Ликбез: Распределенные Системы Хранения Данных На Практике Для Администраторов Среднего И Крупного Бизнеса

- все это отдается оркестровочному ПО, и оно приводит его к той виртуальной архитектуре, которая вам нужна в конец.

Грубо говоря, он объединяется в один том или позволяет нарезать его как угодно.

Вас не волнует, какие интерфейсы есть у этих систем.

SDS будет построен сверху.

Вам все равно, какие функции могут и не могут выполнять ваши устройства хранения данных (опять же, теперь они могут делать то, что им нужно: решает программное обеспечение наверху).

Заодно рассмотрим пару типовых задач с конкретным железом и ценами.

С этого момента все это пространство становится общим.

Но при этом программа понимает, что там должны храниться «быстрые» данные, а медленные архивные данные вообще должны храниться там.

Вы, как системный администратор, грубо говоря, перестаете мыслить категориями «RAID-группа на СХД», а начинаете думать категориями «есть набор данных, их нужно поместить в FAST-профиль».

Разумеется, договорившись с мастером или предварительно настроив, что этот FAST-профиль находится на таких-то дисках таких-то СХД.

Это же программное обеспечение использует в качестве кэша оперативную память серверов (контроллеров виртуальных хранилищ).

То есть обычная оперативная память x86 размером до 1ТБ, кэш, который читает и записывает, плюс есть такие вкусности, как превентивное чтение, группировка блоков, многопоточность и действительно интересный Random Wrire Accelerator (но об этом ниже).

То есть оно очень и очень существенное, но освоить его на первых порах довольно сложно.

Нужны новые подходы и новое понимание архитектуры.

Замечу, что ничего прямо принципиально нового в самой концепции Software-Defined нет, а базовые принципы были применены как минимум 15 лет назад. Просто он назывался по-другому и встречался не везде.

В этом посте мы обсуждаем SDS (Software Defined Storage), речь идет только о системах хранения, дисковых массивах и других устройствах хранения данных, а также их интерфейсах.

Я расскажу о технологиях на базе программного обеспечения DataCore. Это далеко не единственный вендор, но он полностью покрывает практически все задачи виртуализации хранилищ данных.

Вот несколько других поставщиков, которые решают проблемы хранения данных в программно-определяемых архитектурах: • EMC со своим ScaleIO позволяет объединить любое количество x86-серверов с дисковыми полками в одно быстрое хранилище.

Здесь теория , и здесь упражняться отказоустойчивая система для отечественных, не самых надежных серверов.

• Отечественный РЭИДИКС .

Вот о них и их грибах .

Их архитектура, заменяющая СХД стоимостью 80–100 тысяч для ряда конкретных задач типа видеомонтажа за 10–20 тысяч долларов.

• У русла реки есть классное решение, с помощью которого мы объединили все отделения банка в системе хранения Москвы вот так , потом увидели это в своей городской локальной сети и сделали квазисинхронную репликацию через кэш.

Серверы в городах 1 и 2 обращаются к СХД в Москве как к своим «вкладным» дискам со скоростями LAN. При необходимости можно работать напрямую (случай 3, аварийное восстановление офиса), но это уже означает обычные задержки сигнала из города в Москву и обратно.

• Кроме того, аналогичные решения существуют в Цитрикс и ряда других вендоров, но, как правило, они больше ориентированы на собственную продукцию компании.

• Нутаникс решает проблемы гиперхранилища, но зачастую стоит дорого, так как делают программно-аппаратный комплекс, а там ПО отделяется от железа только на очень и очень больших объемах.

• КРАСНАЯ ШАПКА предлагает продукцию CEPH или Gluster, но эти, казалось бы, красноглазые ребята поддержали санкции.

У меня больше всего опыта работы с Ядро данных , поэтому прошу заранее простить (и дополнить), если я ненароком обойду чьи-то крутые функции.

Собственно, что нужно знать об этой компании: американцы (но не присоединились к санкциям, так как даже не котировались на бирже), на рынке уже 18 лет, все это время пилят под под руководством того же парня, что и в самом начале, единственный продукт — программное обеспечение для построения систем хранения данных — SANsymphony-V, которое я в дальнейшем для краткости буду называть SSV. Поскольку их начальник — инженер, они были помешаны на технологиях, но совершенно не думали о маркетинге.

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

Со стороны потребителя (хоста) SSV выглядит как обычная система хранения, но по сути это диск, подключаемый напрямую к серверу.

В нашем случае на практике это обычно виртуальный многопортовый диск, две физические копии которого доступны через два разных узла DataCore. Это приводит к первой базовой функции SSV — синхронной репликации, и большинство фактически используемых LUN DataCore являются отказоустойчивыми дисками.

Программное обеспечение может быть размещено на любом x86-сервере (практически), в качестве ресурсов могут использоваться практически любые блочные устройства: внешние системы хранения данных (FC, iSCSI), внутренние накопители (в том числе PCI-SSD), DAS, JBOD, даже подключенные облачные хранилища.

Почти — потому что есть требования к оборудованию.

Виртуальные диски SSV могут быть представлены любому хосту (за исключением ОС IBM i5).

Начнем с кэширования.

Кэш здесь — это вся свободная оперативная память сервера, на котором установлен ДЦ, работает как на запись, так и на чтение, максимальный объем — 1Тб.

Те же ScaleIO и RAIDIX не используют оперативную память, а нагружают диски «своих» серверов или контроллеров.

Это обеспечивает более быстрый кэш.

Эта архитектура постоянного тока ориентирована на скорость и надежность.

На мой взгляд, для практических задач среднего бизнеса сегодня мы получаем самый быстрый и в то же время вполне доступный кэш.

В этом же кэше, на основе оперативной памяти сервера, есть функция оптимизации случайной записи, например, под OLTP-нагрузку.

Принцип работы оптимизатора очень просто: хост кидает случайные блоки данных (например SQL) на виртуальный диск, они попадают в кэш (ОЗУ), который технологически способен быстро записывать случайные блоки, располагая эти блоки последовательно.

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

Сюда также входит упреждающее чтение, группировка блоков, многопоточность, консолидация блоков, защита от шторма при загрузке/входе в систему, эффект блендера.

Если управляющее программное обеспечение понимает, что делает хост-приложение (например, считывает VDI-образ по стандартной схеме), то чтение можно производить до того, как хост запросит данные, поскольку последние несколько раз в Такая же ситуация.

Разумно положить его в кэш в тот момент, когда станет понятно, что именно он там делает. Автоматическое многоуровневое распределение — это когда любой виртуальный диск строится на основе пула, который может включать в себя самые разные носители — от СХД PCI-SSD и FC до медленных SATA и даже внешних облачных хранилищ.

Каждому из носителей мы присваиваем уровень от 0 до 14, и программа автоматически перераспределяет блоки между носителями в зависимости от частоты доступа к блоку.

То есть архивированные данные хранятся на SATA и других медленных носителях, а горячие фрагменты базы данных, например, на SSD. При этом все доступные ресурсы используются автоматически и оптимально; это не ручная обработка файлом.

Оценка статистики и последующее перемещение блоков происходит по умолчанию раз в 30 секунд, но если это не создает задержку для текущих задач чтения и записи.

Балансировка нагрузки присутствует в виде аналога RAID 0 — чередования между физическими носителями в дисковом пуле, а также возможности полноценно использовать оба узла кластера (активный-активный) в качестве основного, что позволяет более эффективно нагрузочные адаптеры и сеть SAN. С помощью SSV можно, например, организовать метрокластер между СХД, которые не поддерживают эту возможность или требуют для этого дополнительного дорогостоящего оборудования.

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

Первый — это SDS, программно-определяемое хранилище.

Классическая «тяжелая» система хранения — это, например, физическая стойка, содержащая RISC-серверы и SSD-матрицу (или массивы HDD).

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

Разница в цене между x86-продуктом китайских трудящихся и СХД аналогичного объёма от того же EMC, HP или другого вендора составляет примерно от двух до двух за аналогичный набор дисков.

Около половины этой разницы связано с архитектурой.

Так что, конечно, можно объединить несколько x86-серверов с дисковыми полками в одну быструю сеть и научить их работать в кластере.

Для этого есть специальное программное обеспечение, например EMC Vipr. Либо можно построить его на базе одного сервера хранения x86, заполнив его дисками под завязку.

SDS на самом деле является таким сервером.

Разница лишь в том, что в 99% случаев на практике это будут 2 ноды, а на бэкенде может быть что угодно.

Технически это два сервера x86. Они работают под управлением ОС Windows и DataCore SSV, между которыми имеются каналы синхронизации (блокировки) и управления (IP).

Эти серверы располагаются между хостом (потребителем) и ресурсами хранения, например кучей полок с дисками.

Ограничение - в обоих должен быть блокированный доступ.

Наиболее понятным описанием архитектуры будет процедура записи блока.

Виртуальный диск представляется хосту как обычное блочное устройство.

Приложение записывает блок на диск, блок попадает в ОЗУ первого узла (1), затем по каналу синхронизации записывается в ОЗУ второго узла (2), затем записывается (3), записывается (4).

Как только блок появляется в двух экземплярах, приложение получает подтверждение записи.

Конфигурация платформы DC и бэкенда зависит только от требований к нагрузке хостов.

Как правильно, производительность системы ограничена ресурсами адаптеров и сети SAN. Второй — Virtual SAN, то есть виртуальное хранилище.

DC SSV располагается в виртуальной машине под управлением ОС Windows Server, а ресурсы хранения, подключенные к этому хосту (гипервизору), отдаются DC. Это могут быть как внутренние диски, так и внешние системы хранения данных; в текущей версии таких узлов от 2 до 64. DC позволяет объединять ресурсы «под» всеми гипервизорами и динамически распределять этот объем.

Также имеется две физические копии каждого блока, как и в предыдущей архитектуре.

На практике это чаще всего внутренние диски сервера.

Практика состоит в том, чтобы собрать отказоустойчивый мини-ЦОД без использования внешнего хранилища: это 2–5 узлов, которые можно добавить, если потребуются новые вычислительные ресурсы или ресурсы хранения.

Это частный пример модной сейчас идеи гиперконвергентной среды, которую используют Google, Amazon и другие.

Проще говоря, можно построить Enterprise-среду, а можно взять кучу не самого надежного и не самого быстрого х86-оборудования, забить машины дисками и полететь захватывать мир по низкой цене.

• На основе того же оборудования и внутренних серверных устройств хранения данных создать виртуальную сеть хранения данных с синхронной репликацией томов с помощью программного обеспечения DataCore. Виртуальный сервер, узел DataCore, развертывается на каждом сервере виртуализации; к узлам DataCore дополнительно подключаются виртуальные диски, созданные на локальных дисковых ресурсах серверов виртуализации.

Эти диски объединяются в пулы дисковых ресурсов, на основе которых создаются зеркальные виртуальные диски.

Диски зеркалируются между двумя узлами DataCore Virtual SAN — таким образом, «исходный» диск располагается в пуле дисковых ресурсов одного узла, а «зеркальная копия» — на втором.

Далее виртуальные диски передаются непосредственно серверам виртуализации (гипервизорам) или виртуальным машинам.

Получается дешево и сердито (коллеги подсказывают: конкурентное решение по цене) и без дополнительного оборудования.

Помимо решения ближайшей задачи, сеть хранения данных получает массу полезного дополнительного функционала: повышение производительности, возможность интеграции с VMware, снимки всего тома и так далее.

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

Вот схема:



Задача № 2. Единая система хранения данных (NAS/SAN).

Все началось с отказоустойчивого кластера Windows для файлового сервера.

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

Было принято решение построить кластер.

Из имеющегося оборудования у заказчика было два сервера Supermicro (один из которых был подключен к SAS JBOD).

Дискового пространства на двух серверах более чем достаточно (около 10 ТБ на каждый сервер), но для организации кластера требуется общее хранилище.

Также планировалось иметь резервную копию данных, так как одна СХД — это единая точка отказа, желательно с CDP, охватывающим рабочую неделю.

Данные должны быть доступны постоянно, максимальное время простоя — 30 минут (и тогда могут полететь головы).

Стандартное решение включало покупку системы хранения и еще одного сервера для резервного копирования.

Решение: • Программное обеспечение DataCore установлено на каждом сервере.

В архитектуре DataCore отказоустойчивый кластер Windows можно развернуть без использования общего хранилища SAN (с использованием внутренних серверных дисков) или использования DAS, JBOD или внешних систем хранения с полной реализацией архитектуры DataCore Unified Storage (SAN & NAS), используя все преимущества возможностей Windows Server 2012, NFS и SMB (CIFS) и предоставления услуг SAN внешним хостам.

Берете три сервера по 24 диска каждый и получаете приемлемый объем и приемлемую производительность для большинства сервисов.

Если вам необходимо организовать зоопарк, более дешевый и простой вариант найти будет сложно.

Сроки такие: последний пример — 8 дней на реализацию.

До дизайна еще около недели.

Мы использовали существующее оборудование и не закупали принципиально новое оборудование.

Мы купили только дополнительные плашки оперативной памяти для кэша.

Лицензия Datacora заняла чуть больше недели, но мы планируем две.

Лицензия ДЦ по объему – в пакетах по 8, 16 ТБ.

Если интересно, могу дать условную розничную цену (важно: на самом деле все достаточно гибко, лицензирование осуществляется по хосту или ТБ и можно выбирать некоторые функции, так что по факту цены очень разные, если нужен расчет для вашего случая, пишите тоже в личное сообщение).

Одной из наших задач была организация сегмента ДМЗ крупной компании.

Для экономии хранилища и оптимизации доступа к локальному хранилищу мы установили просто DC. У них не было общего ядра SAN с DMZ, поэтому нужно было либо покупать систему хранения данных и еще одно аппаратное обеспечение типа межсетевого экрана с насадками для безопасного доступа внутрь, либо проявить смекалку.

Мы объединили 3 хоста виртуализации в единое пространство и оптимизировали доступ.

Вышло дешево и быстро.

В другой задаче нам нужно было оптимизировать доступ для SQL. Там мы смогли использовать старые медленные хранилища.

Благодаря кэшу DC запись происходила в десятки раз быстрее, чем запись напрямую.

Есть RAID Striping, что полезно для некоторых ситуаций (можно построить программные RAID0 и RAID1, даже если подключенный DAS не умеет это делать).

Хорошие отчеты — это визуальные и статистические инструменты для предоставления данных о всевозможных параметрах производительности, указывающих на узкие места.

Контроль качества обслуживания позволяет СУБД и критически важным приложениям работать быстрее, устанавливая ограничения на трафик ввода-вывода для менее критичных рабочих нагрузок.

Я вырубал узлы при тестировании мощности (в разумных пределах, сохраняя необходимое количество узлов для корректного восстановления), но уловить повреждения не смог.

Синхронное зеркалирование и автоматическое переключение при сбое — имеется синхронная репликация и автоматические и настраиваемые механизмы восстановления после сбоев.

Функция самовосстановления дисковых пулов заключается в следующем: если физический диск в пуле выходит из строя или помечен для замены, DataCore автоматически восстанавливает пул до доступных ресурсов.

Плюс журнал изменений на диске с возможностью восстановления из любого состояния и в любое время.

Плановая замена дисков, естественно, производится без перерыва в работе.

Как обычно, данные распределяются между другими экземплярами, а затем при первой же возможности том «переползает» на новый диск.

Миграция между дата-центрами осуществляется примерно по аналогичному принципу, только «замена дисков» носит массовый характер.

Существует Virtual Disk Migration — простая и эффективная миграция данных с физических ресурсов на виртуальные и наоборот. И без остановки приложений.

Есть возможность у каждого подключиться к живой установке и потрогать консоль своими руками.