администрирование схд что это
О сетях хранения данных
Решил написать небольшую статейку о сетях хранения данных (СХД), тема эта достаточно интересная, но на Хабре почему-то не раскрыта. Постараюсь поделиться личным опытом по построению и поддержке SAN.
Что это?
Сеть хранения данных, или Storage Area Network — это система, состоящая из собственно устройств хранения данных — дисковых, или RAID — массивов, ленточных библиотек и прочего, среды передачи данных и подключенных к ней серверов. Обычно используется достаточно крупными компаниями, имеющими развитую IT инфраструктуру, для надежного хранения данных и скоростного доступа к ним.
Упрощенно, СХД — это система, позволяющая раздавать серверам надежные быстрые диски изменяемой емкости с разных устройств хранения данных.
Немного теории.
Сервер к хранилищу данных можно подключить несколькими способами.
Первый и самый простой — DAS, Direct Attached Storage (прямое подключение), без затей ставим диски в сервер, или массив в адаптер сервера — и получаем много гигабайт дискового пространства со сравнительно быстрым доступом, и при использовании RAID-массива — достаточную надежность, хотя копья на тему надежности ломают уже давно.
Однако такое использование дискового пространства не оптимально — на одном сервере место кончается, на другом его еще много. Решение этой проблемы — NAS, Network Attached Storage (хранилище, подключенное по сети). Однако при всех преимуществах этого решения — гибкости и централизованного управления — есть один существенный недостаток — скорость доступа, еще не во всех организациях внедрена сеть 10 гигабит. И мы подходим к сети хранения данных.
Главное отличие SAN от NAS (помимо порядка букв в аббревиатурах) — это то, каким образом видятся подключаемые ресурсы на сервере. Если в NAS ресурсы подключаются протоколам NFS или SMB, в SAN мы получаем подключение к диску, с которым можем работать на уровне операций блочного ввода-вывода, что гораздо быстрее сетевого подключения (плюс контроллер массива с большим кэшем добавляет скорости на многих операциях).
Используя SAN, мы сочетаем преимущества DAS — скорость и простоту, и NAS — гибкость и управляемость. Плюс получаем возможность масштабирования систем хранения до тех пор, пока хватает денег, параллельно убивая одним выстрелом еще несколько зайцев, которых сразу не видно:
* снимаем ограничения на дальность подключения SCSI-устройств, которые обычно ограничены проводом в 12 метров,
* уменьшаем время резервного копирования,
* можем грузиться с SAN,
* в случае отказа от NAS разгружаем сеть,
* получаем большую скорость ввода-вывода за счет оптимизации на стороне системы хранения,
* получаем возможность подключать несколько серверов к одному ресурсу, то нам дает следующих двух зайцев:
o на полную используем возможности VMWare — например VMotion (миграцию виртуальной машины между физическими) и иже с ними,
o можем строить отказоустойчивые кластеры и организовывать территориально распределенные сети.
Что это дает?
Помимо освоения бюджета оптимизации системы хранения данных, мы получаем, вдобавок к тому что я написал выше:
* увеличение производительности, балансировку нагрузки и высокую доступность систем хранения за счет нескольких путей доступа к массивам;
* экономию на дисках за счет оптимизации расположения информации;
* ускоренное восстановление после сбоев — можно создать временные ресурсы, развернуть на них backup и подключить к ним сервера, а самим без спешки восстанавливать информацию, или перекинуть ресурсы на другие сервера и спокойно разбираться с умершим железом;
* уменьшение время резервного копирования — благодаря высокой скорости передачи можно бэкапиться на ленточную библиотеку быстрее, или вообще сделать snapshot (мгновенный снимок) с файловой системы и спокойно архивировать его;
* дисковое место по требованию — когда нам нужно — всегда можно добавить пару полок в систему хранения данных.
* уменьшаем стоимость хранения мегабайта информации — естественно, есть определенный порог, с которого эти системы рентабельны.
* надежное место для хранения mission critical и business critical данных (без которых организация не может существовать и нормально работать).
* отдельно хочу упомянуть VMWare — полностью все фишки вроде миграции виртуальных машин с сервера на сервер и прочих вкусностей доступны только на SAN.
Из чего это состоит?
Как я писал выше — СХД состоит из устройств хранения, среды передачи и подключенных серверов. Рассмотрим по порядку:
Системы хранения данных обычно состоят из жестких дисков и контроллеров, в уважающей себя системе как правило всего по 2 — по 2 контроллера, по 2 пути к каждому диску, по 2 интерфейса, по 2 блока питания, по 2 администратора. Из наиболее уважаемых производителей систем следует упомянуть HP, IBM, EMC и Hitachi. Тут процитирую одного представителя EMC на семинаре — «Компания HP делает отличные принтеры. Вот пусть она их и делает!» Подозреваю, что в HP тоже очень любят EMC. Конкуренция между производителями нешуточная, впрочем, как и везде. Последствия конкуренции — иногда вменяемые цены за мегабайт системы хранения и проблемы с совместимостью и поддержкой стандартов конкурентов, особенно у старого оборудования.
Среда передачи данных. Обычно SAN строят на оптике, это дает на текущий момент скорость в 4, местами в 8 гигабит на канал. При построении раньше использовались специализированные хабы, сейчас больше свитчи, в основном от Qlogic, Brocade, McData и Cisco (последние два на площадках не видел ни разу). Кабели используются традиционные для оптических сетей — одномодовые и многомодовые, одномодовые более дальнобойные.
Внутри используется FCP — Fibre Channel Protocol, транспортный протокол. Как правило внутри него бегает классический SCSI, а FCP обеспечивает адресацию и доставку. Есть вариант с подключением по обычной сети и iSCSI, но он обычно использует (и сильно грузит) локальную, а не выделенную под передачу данных сеть, и требует адаптеров с поддержкой iSCSI, ну и скорость помедленнее, чем по оптике.
Есть еще умное слово топология, которое встречается во всех учебниках по SAN. Топологий несколько, простейший вариант — точка-точка (point to point), соединяем между собой 2 системы. Это не DAS, а сферический конь в вакууме простейший вариант SAN. Дальше идет управляемая петля (FC-AL), она работает по принципу «передай дальше» — передатчик каждого устройства соединен с приемником последующего, устройства замкнуты в кольцо. Длинные цепочки имеют свойство долго инициализироваться.
Ну и заключительный вариант — коммутируемая структура (Fabric), она создается с помощью свитчей. Структура подключений строится в зависимости от количества подключаемых портов, как и при построении локальной сети. Основной принцип построения — все пути и связи дублируются. Это значит, что до каждого устройства в сети есть минимум 2 разных пути. Здесь тоже употребимо слово топология, в смысле организации схемы подключений устройств и соединения свитчей. При этом как правило свитчи настраиваются так, что сервера не видят ничего, кроме предназначенных им ресурсов. Это достигается за счет создания виртуальных сетей и называется зонированием, ближайшая аналогия — VLAN. Каждому устройству в сети присваивается аналог MAC-адреса в сети Ethernet, он называется WWN — World Wide Name. Он присваивается каждому интерфейсу и каждому ресурсу (LUN) систем хранения данных. Массивы и свитчи умеют разграничивать доступ по WWN для серверов.
А дальше на системах хранения нарезаются ресурсы, они же диски (LUN) для каждого сервера и оставляется место в запас, все включается, установщики системы прописывают топологию, ловят глюки в настройке свитчей и доступа, все запускается и все живут долго и счастливо*.
Я специально не касаюсь разных типов портов в оптической сети, кому надо — тот и так знает или прочитает, кому не надо — только голову забивать. Но как обычно, при неверно установленном типе порта ничего работать не будет.
Из опыта.
Обычно при создании SAN заказывают массивы с несколькими типами дисков: FC для скоростных приложений, и SATA или SAS для не очень быстрых. Таким образом получаются 2 дисковые группы с различной стоимостью мегабайта — дорогая и быстрая, и медленная и печальная дешевая. На быструю вешаются обычно все базы данных и прочие приложения с активным и быстрым вводом-выводом, на медленную — файловые ресурсы и все остальное.
Если SAN создается с нуля — имеет смысл строить ее на основе решений от одного производителя. Дело в том, что, несмотря на заявленное соответствие стандартам, существуют подводные грабли проблемы совместимости оборудования, и не факт, что часть оборудования будет работать друг с другом без плясок с бубном и консультаций с производителями. Обычно для утряски таких проблем проще позвать интегратора и дать ему денег, чем общаться с переводящими друг на друга стрелки производителями.
Если SAN создается на базе существующей инфраструктуры — все может быть сложно, особенно если есть старые SCSI массивы и зоопарк старой техники от разных производителей. В этом случае имеет смысл звать на помощь страшного зверя интегратора, который будет распутывать проблемы совместимости и наживать третью виллу на Канарах.
Часто при создании СХД фирмы не заказывают поддержку системы производителем. Обычно это оправдано, если у фирмы есть штат грамотных компетентных админов (которые уже 100 раз назвали меня чайником) и изрядный капитал, позволяющий закупить запасные комплектующие в потребных количествах. Однако компетентных админов обычно переманивают интеграторы (сам видел), а денег на закупку не выделяют, и после сбоев начинается цирк с криками «Всех уволю!» вместо звонка в саппорт и приезда инженера с запасной деталью.
Поддержка обычно сводится к замене умерших дисков и контроллеров, ну и к добавлению в систему полок с дисками и новых серверов. Много хлопот бывает после внезапной профилактики системы силами местных специалистов, особенно после полного останова и разборки-сборки системы (и такое бывает).
Про VMWare. Насколько я знаю (спецы по виртуализации поправьте меня), только у VMWare и Hyper-V есть функционал, позволяющий «на лету» перекидывать виртуальные машины между физическими серверами. И для его реализации требуется, чтобы все сервера, между которыми перемещается виртуальная машина, были подсоединены к одному диску.
Про кластеры. Аналогично случаю с VMWare, известные мне системы построения отказоустойчивых кластеров (Sun Cluster, Veritas Cluster Server) — требуют подключенного ко всем системам хранилища.
Пока писал статью — у меня спросили — в какие RAIDы обычно объединяют диски?
В моей практике обычно делали или по RAID 1+0 на каждую дисковую полку с FC дисками, оставляя 1 запасной диск (Hot Spare) и нарезали из этого куска LUN-ы под задачи, или делали RAID5 из медленных дисков, опять же оставляя 1 диск на замену. Но тут вопрос сложный, и обычно способ организации дисков в массиве выбирается под каждую ситуацию и обосновывается. Та же EMC например идет еще дальше, и у них есть дополнительная настройка массива под приложения, работающие с ним (например под OLTP, OLAP). С остальными вендорами я так глубоко не копал, но догадываюсь, что тонкая настройка есть у каждого.
* до первого серьезного сбоя, после него обычно покупается поддержка у производителя или поставщика системы.
Поскольку в песочнице комментариев нет, закину в личный блог.
Разбираемся вместе: что такое система хранения данных
Надёжное хранение данных — задача, которую приходится решать каждому бизнесу. Но когда повышаются объёмы информации, растут и требования к надёжности хранения данных. Чтобы организовать наилучшую работу с информацией, стоит обратиться к СХД — системе хранения данных.
В материале расскажем о том, что такое и как устроены СХД, какие проблемы они решают, как классифицируются и на какие характеристики следует смотреть в первую очередь, если вы не так давно в этой отрасли.
Что такое СХД и какие проблемы она решает
СХД (Система хранения данных или Сервер хранения данных) — это устройство для хранения и управления данными, их резервного копирования. Она призвана решить типичные проблемы, связанные с растущими объёмами информации в любой организации.
Если раньше все данные могли храниться буквально на одном жёстком диске, то сейчас любая функциональная система требует отдельного хранилища – к примеру, серверов электронной почты, СУБД, домена и так далее. Поэтому с помощью СХД можно организовать децентрализацию информации (рассредоточение её по разным хранилищам).
Лавинообразный рост размера информации, который вызван, с одной стороны, ужесточением регулирования и требованием сохранять всё больше информации, связанной с ведением бизнеса. С другой стороны, ужесточение конкуренции требует всё более глубокого анализа информации о рынке, клиентах, их предпочтениях, заказах и действиях конкурентов. Но количества жёстких дисков, которые вы можете установить в конкретный сервер, не может покрыть необходимую системе ёмкость. В этом тоже может помочь СХД.
Хранение данных — не единственная функция современных СХД. Они также предлагают экономить место в хранилище с помощью дедупликации и компрессии. Компрессия позволяет системе сжимать файлы, исключая избыточную информацию, а дедупликация помогает экономить место для хранения, исключая избыточные файлы и оставляя лишь ссылки на них.
Некоторым компаниям тяжело контролировать и ограничивать доступ из-за политики безопасности предприятия. Например, касается как доступа к данным по существующим для этого каналам (локальная сеть), так и физического доступа к носителям.
Также отметим высокие затраты используемых ресурсов для поддержания работоспособности всей информационной системы предприятия, начиная от необходимости содержать большой штат квалифицированного персонала и заканчивая многочисленными недешёвыми аппаратными решениями.
Устройство СХД
Основные компоненты типичной СХД — массив жёстких дисков (HDD или SSD), кэш-память, контроллер дискового массива, внешний корпус и несколько блоков питания.
Главная фишка СХД — это скорость работы дисковой системы. Например, если ваши диски стоят внутри сервера они не будут работать с такой же производительностью, как сервер подключённый к СХД.
Какие бывают системы хранения данных
Существует классификация СХД: они делятся на файловые, блочные и объектные. Каждый вид СХД определяет в каком виде хранятся данные, способ доступа к ним, и, как результат, простоту управления и скорость доступа к данным.
Файловые
Хранят информацию в виде файлов, собранных в каталоги (папки). Файлы организуются и извлекаются благодаря метаданным, которые сообщают, где находится тот или иной файл. Условно такую систему можно представить в виде каталога.
Блочные
Данные хранятся независимо друг от друга. Каждому такому блоку присваивается идентификатор, который позволяет системе размещать каждый блок, где ей удобно. Блочные хранилища не полагаются на единственный путь к данным (в отличии от файловых хранилищ).
Объектные
Расщепляют файлы на «объекты», которые находятся в одном, общем хранилище. Оно может быть поделено на тома, каждый из которых может иметь уникальный идентификатор и подробные метаданные, которые позволяют быстро находить объекты. Подобный подход — это распределённая система.
Принцип работы СХД — NAS, SAN и DAS
Существует несколько аппаратных компонентов, программного обеспечения и протоколов, которые в конечном итоге придают решениям для хранения данных их особые свойства.
На основе классификации выше выделяют два основных типа СХД: они различаются уровнем хранения, чтения и записи данных.
О каждом из них расскажем подробнее.
NAS расшифровывается как Network Attached Storage, что можно условно перевести как сетевое хранилище. Поскольку данные обрабатываются на уровне файлов, сервер представляется NAS как сетевой сервер со своей собственной файловой системой.
Если объяснить проще — представьте себе стационарный компьютер, который подключён к домашнему роутеру. На нём хранятся фото, видео, документы и другие данные. Сетевой доступ разрешен всем пользователям — приблизительно так выглядит NAS.
NAS-хранилище может принимать разные формы. Например, к производственному серверу могут быть подключены другие серверы, виртуальные машины или так называемые дисковые станции, на которых находится другое количество съёмных жестких дисков.
Преимущества NAS:
Недостатки NAS:
DAS расшифровывается как Direct Attach Storage — прямое подключение к рабочей станции, хранилищу). Например, подключение внешнего диска по USB условно можно назвать DAS.
Из принципиальной простоты архитектуры DAS следуют её основные преимущества: доступная цена и относительная простота внедрения. Кроме того, такой конфигурацией легче управлять ввиду хотя бы того, что число элементов системы мало.
Внутри системы находится блок питания, охлаждение и RAID-контроллер, который обеспечивает надёжность и отказоустойчивость хранилища. Управляется при помощи встроенной операционной системы.
Достоинства DAS:
Недостатки DAS:
В свою очередь SAN — это сети хранения данных. Как правило они представлены в виде внешних хранилищ на нескольких сетевых блочных устройствах и реализованы в виде протокола FC (Fiber Channel) или iSCSI (Internet Small Computer System Interface). Это блочный доступ непосредственно к устройству хранения — диску или наборов дисков в виде RAID-групп или логических устройств.
Кстати, вышеупомянутый DAS может быть очень мощным и часто более дешёвым, чем SAN. Однако в то же время недостаток DAS в том, что он не может быть легко расширен — количество подключённых компьютеров ограничено физическим количеством портов SAS на DAS (обычно их всего четыре). Поэтому многие компании и учреждения предпочитают выбирать блочные хранилища, подключенные через SAN.
Преимущества SAN:
Недостатки SAN:
Как выбрать СХД?
В первую очередь нужно понимать, какие задачи она будет решать. Важно определиться с несколькими базовыми параметрами.
Тип данных
Разные типы данных требуют разной скорости доступа, технологий обработки, компрессии и так далее. К примеру, виртуальный СХД для работы с большими медиа-файлами отличается от той системы, которая будет работать с неструктурированными данными для нейросети.
Объём данных
От этого зависит выбор дисковых накопителей. Иногда можно обойтись SSD потребительского класса — если известно, что ёмкость СХД даже в худшем случае не будет превышать 300 ГБ, а скорость доступа не критична.
Отказоустойчивость
Необходимо представлять, какова стоимость потери данных за определённое время. Это поможет рассчитать RPO (Recovery-Point Objective) и RTO (Recovery Time Objective), а также избежать лишних затрат на резервное копирование. Бэкапы, бэкапы и ещё раз бэкапы.
Производительность
Если СХД закупается под новый проект (нагрузку которого сложно предугадать), то лучше пообщаться с коллегами, которые уже решали эту задачу или протестировать СХД.
Вендор
Иногда даже для ресурсоемкого сервиса подойдет бюджетное или среднеуровневое решение (StarWind, Huawei, Fujitsu). Однако у топовых производителей — NetApp, HPE, Dell EMC — линейка продуктов достаточно широкая, и сравнительно недорогие СХД здесь также можно найти. В любом случае, желательно сильно не расширять количество вендоров на одной инфраструктуре.
Если сейчас вы находитесь в поисках решения для работы с данными, арендовать выделенный web-сервер и СХД (системы хранения данных) можно в одном из наших ЦОД. Мы, со своей стороны, обеспечим сервер быстрым соединением с интернетом на скорости до 10 Гбит/сек, постоянным подключением к электричеству и поддержкой 27/7 ;).
Большой ликбез: распределённые системы хранения данных в практической привязке для админов среднего и крупного бизнеса
Современные сети и дата-центры бодро шагают к полной и тотальной программно-определяемой схеме, когда фактически неважно, какое железо вы напихаете внутрь, всё будет на софте. У сотовых операторов это началось с того, что им не хотелось ставить по 20 антенн на дом (у них узлы переконфигурируются, меняют частоты и параметры просто обновлением конфига), а в дата-центрах сначала с виртуализации серверов, которая теперь мастхэв, а потом продолжилось и виртуализацией хранилищ.
Но вернёмся в Россию 2015 года. Ниже я покажу, как «из подручных средств» (x86 машин и любых «хранилок») сэкономить денег, повысить надёжность и решить ещё ряд типовых для сисадминов среднего и крупного бизнеса задач.
На этой схеме видны обе архитектуры, о которых пойдет речь. SDS — два красных контроллера в центре с любым бекэндом, от внутренних дисков до FC полок и облаков. И виртуальный SAN, на схеме Hyper-converged storage.
Кому это надо и зачем
Фактически SDS-софт для хранения данных создаёт управляющий сервер (или кластер), в который подключаются разные типы хранилищ: дисковые полки, диски и оперативная память серверов (в качестве кэша), PCI-SSD, SSD-полки, а также отдельные «шкафы» систем хранения данных разного типа и моделей от разных вендоров и с разными дисками и протоколами подключения.
С этого момента всё это пространство становится общим. Но при этом ПО понимает, что «быстрые» данные надо хранить там-то, а медленные архивные — вообще воооон там. Вы же как сисадмин, грубо говоря, перестаёте думать категориями «RAID-группа на СХД», а начинаете мыслить такими понятиями, как «есть набор данных, надо разместить их в профиле БЫСТРЫЕ». Разумеется, согласившись с мастером или преднастроив, что этот профиль БЫСТРЫЕ находится на таких-то дисках таких-то СХД.
Это же ПО использует RAM серверов (контроллеров виртуальной СХД) в качестве кэша. То есть обычная x86 ОЗУ, до 1TB размером, чз кэш и читает и пишет, плюс есть плюшки типа превентивного чтения, группировки блоков, многопоточности и реально интересная Random Wrire Accelerator (но об этом ниже).
Что такое Software-defined Data Center и как SDS входят в философию SDDC
Разница между программно-определяемыми инфраструктурами и обычными «статическими» примерно такие же, какие случились между старыми добрыми электросхемами на лампах и «новыми» на транзисторах. То есть весьма и весьма существенная, но освоить это поначалу довольно сложно. Нужны новые подходы и новое понимание архитектуры.
Отмечу, что ничего прямо принципиально нового в самой концепции Software-defined нет, и базовые принципы применялись ещё лет 15 минимум назад. Просто называлось это иначе и встречалось далеко не везде.
В этом посте мы обсуждаем SDS (Software Defined Storage), речь только про СХД, дисковые массивы и другие устройства хранения, а также их интерфейсы.
Говорить я буду про технологии на базе софта DataCore. Это далеко не единственный вендор, но он покрывает практически все задачи виртуализации хранилищ данных полностью.
Вот несколько других вендоров, которые решают задачи хранения данных на программно-определяемых архитектурах:
• EMC с их ScaleIO позволяет объединять любое количество x86-серверов с дисковыми полками в единое быстрое хранилище. Вот теория, а вот практика отказоустойчивой системы для отечественных не самых надёжных серверов.
Их архитектура, заменяющая для ряда специфических задач типа видеомонтажа за 10–20 тысяч долларов СХД стоимостью в 80–100 тысяч
• У Riverbed есть крутое решение, с помощью которого мы соединяли все филиалы банка в московской СХД так, то они видели её в своей LAN-сети города и делали квазисинхронную репликацию через кэш.
Сервера в городах 1 и 2 адресуются к СХД в Москве как к своим дискам «в корпусе» с LAN-скоростями. При необходимости можно работать напрямую (случай 3, аварийное восстановление офиса), но это уже означает обычные задержки сигнала от города до Москвы и обратно.
• Кроме того, подобные решения есть у Citrix и ряда других вендоров, но, как правило, они более заточены под собственные продукты компании.
• Nutanix решает задачи гиперхранилищ, но часто дороговат, поскольку они делают программно-аппаратный комплекс, и там софт отделяется от железа только на очень-очень больших объёмах.
• RED HAT предлагает продукты CEPH или Gluster, но эти вроде бы на первый взгляд красноглазые парни поддержали санкции.
У меня наибольший опыт именно с DataCore, поэтому прошу заранее простить (и дополнить), если я ненароком обойду чьи-то крутые функции.
Собственно, что надо знать про эту компанию: американцы (но не присоединились к санкциям, поскольку даже не размещались на бирже), на рынке 18 лет, всё это время пилят под руководством всё того же мужика, что и в самом начале, один-единственный продукт — софт для построения СХД — SANsymphony-V, которую я дальше буду называть для краткости SSV. Поскольку их главный — инженер, они угорали по технологиям, но вообще не думали о маркетинге. В результате их как таковых никто не знал до последнего года, а зарабатывали они тем, что встраивали свои технологии в чужие партнёрские решения не под своим брендом.
Про симфонию
SSV — это софтверное хранилище. Со стороны потребителя (хоста) SSV выглядит как обычное СХД, по факту — как диск, воткнутый прямо в сервер. В нашем случае на практике обычно это виртуальный многопортовый диск, две физические копии которого доступны через две разные ноды DataCore.
Отсюда следуют первая базовая функция SSV — синхронная репликация, и большая часть реально используемых LUN’ов DataCore — это отказоустойчивые диски.
Софт может быть размещён на любом x86 сервере (почти), в качестве ресурсов могут быть использованы почти любые блочные устройства: внешние СХД (FC, iSCSI), внутренние диски (включая PCI-SSD), DAS, JBOD, вплоть до подключённых облачных хранилищ. Почти — потому что есть требования к железу.
Виртуальные диски SSV может презентовать любому хосту (исключение ОС IBM i5).
Простое применение (виртуализатор / FC/iSCSI таргет):
И вот поинтереснее:
Сладкая функциональность
В SSV есть целый набор функций — кэширование, балансировка нагрузки, Auto-Tiering и Random Write Accelerator.
Начнём с кэширования. Кэш тут — это вся свободная оперативная память сервера, на котором установлен DC, работает и на запись и на чтение, максимальный объём 1Tb. Те же ScaleIO и RAIDIX не используют оперативку, зато нагружают диски «своих» серверов или контроллеров. Это обеспечивает более быстрый кэш.
В этой DC-архитектуре ставка сделана на скорость и надёжность. На мой взгляд, для практических задач среднего бизнеса сегодня получается самый быстрый и при этом вполне доступный кэш.
В этом же кэше на базе ОЗУ серверов работает функция оптимизация рандомной записи, например, под OLTP-нагрузку.
Принцип у оптимизатора очень простой: хост закидывает на виртуальный диск случайные блоки данных (например SQL), они попадают в кэш (ОЗУ), который технологически умеет писать рандомные блоки быстро за счёт упорядочивания этих блоков в последовательности. Когда набирается достаточный массив последовательных данных, они переносятся на дисковую подсистему.
Ещё примерно тут делается упреждающее чтение, группирование блоков, многопоточность, консолидация блоков, защита от boot/login — шторма, блендер-эффекта. Если управляющий софт понимает, что делает приложение хоста (например, читает VDI-образ по стандартной схеме), то чтение может производиться раньше, чем хост запросит данные, потому что то же самое он вычитывал последние несколько раз в такой же ситуации. Разумно положить это в кэш в момент, когда станет понятно, что именно он там делает.
Auto-Tiering — это когда любой виртуальный диск базируется на пуле, в который могут быть включены самые разные носители — от PCI-SSD и FC СХД до медленных SATA и даже внешних облачных хранилищ. Каждому из носителей присваиваем уровень от 0 до 14, и софт автоматически перераспределяет блоки между носителями, в зависимости от частоты обращения к блоку. То есть архивные данные кладутся на SATA и прочие медленные носители, а горячие фрагменты БД, например, на SSD. Причём автоматически и оптимальным образом используются все доступные ресурсы, это не ручная обработка напильником.
Оценка статистики и последующее перемещение блоков происходит по умолчания раз в 30 секунд, но в случае если это не создаст задержки для текущих задач чтения и записи. Балансировка нагрузки присутствует в виде аналога RAID 0 — striping между физическими носителями в дисковом пуле, а также как возможность полноценно использовать обе ноды кластера (active-active) в качестве основной, что позволяет эффективнее нагрузить адаптеры и SAN-сеть.
С помощью SSV можно, например, организовать метрокластер между СХД, которые не поддерживают такую возможность или требуют дополнительного дорогостоящего оборудования для этого. И при этом не потерять (при наличии быстрого канала между узлами), а вырасти в производительности и функционале, плюс иметь запас по производительности.
Архитектура
Архитектур у SSV всего две.
Первая — SDS, программно-определяемое хранилище. Классическая «тяжёлая» СХД представляет собой, к примеру, физическую стойку, где есть RISC-сервера и SSD-фабрика (либо HDD-массивы). Кроме, собственно, цены дисков, стоимость этой стойки во многом определяется разницей архитектур, очень важной для решений повышенной надёжности (например банков). Разница в цене между x86-й поделкой китайских тружеников и похожей по объёму СХД того же EMC, HP или другого вендора составляет от порядка до двух при аналогичном наборе дисков. Примерно половина этой разницы приходится на архитектуру.
Так вот, конечно же, можно объединить несколько x86-х серверов с дисковыми полками в одну быструю сеть и научить работать в качестве кластера. Для этого есть специальное ПО, например EMC Vipr. Или можно построить на базе одного x86-го сервера СХД, забив его дисками под завязку.
SDS — это фактически такой сервер. С тем лишь отличием, что в 99% случаев на практике это будут 2 ноды, а на бэкенде может быть всего что угодно.
Технически это два x86 сервера. На них стоит ОС Windows и DataCore SSV, между ними линки синхронизации (блок) и управления (IP). Эти сервера размещены между хостом (потребителем) и ресурсами хранения, например — кучей полок с дисками. Ограничение — должен быть блочный доступ и там и там.
Наиболее понятным описанием к архитектуре будет процедура записи блока. Виртуальный диcк презентован хосту как обычное блочное устройство. Приложение пишет на диск блок, блок попадает в ОЗУ первого узла (1), затем по каналу синхронизации записывается в ОЗУ второго узла (2), затем записано (3), записано (4).
Как только блок появляется в двух копиях, приложение получает подтверждение записи. Конфигурация платформы DC и бэкенда зависит только от требований по нагрузке со стороны хостов. Как правильно производительность системы ограничена ресурсами адаптеров и SAN-сети.
Вторая — это Virtual SAN, то есть виртуальная СХД. DC SSV размещается в виртуальной машине с ОС Windows Server, в распоряжение DC отдаются ресурсы хранения, подключённые к этому хосту (гипервизору). Это могут быть как внутренние диски, так и внешние СХД, таких нод бывает от 2 до 64 штук в текущей версии. DC позволяет объединить ресурсы «под» всеми гипервизорами и динамически распределить этот объём.
Физических копий каждого блока также две, как в предыдущей архитектуре. На практике это чаще всего внутренние диски сервера. Практика — собрать отказоустойчивый мини-ЦОД без использования внешнего хранилища: это 2–5 нод, которые можно добавлять при необходимости новых вычислительных или ресурсов хранения. Это частный пример модной сейчас идеи гиперконвергентной среды, которая используется Google, Amazon и прочими.
Проще говоря, можно построить Enterprise-среду, а можно взять кучу не самой надёжной и не самой быстрой x86-техники, забить машины дисками и полететь захватывать мир по мелкому прайсу.
Вот что умеет получившаяся система:
Две практические задачи
Необходимо объединить в единый территориально распределённый кластер виртуализации VMware vSphere 5.5, обеспечиться реализацию функций отказоустойчивости и резервного копирования с помощью технологий:
• технология высокой доступности VMware High Availability;
• технология балансировки нагрузки VMware DRS;
• технология резервирования каналов данных;
• технология виртуальной сети хранения данных.
Обеспечить следующие режимы работы:
1) Штатный режим работы.
Штатный режим работы характеризуется функционированием всех ВМ в Подсистеме виртуализации ЦОД и РЦОД.
2) Аварийный режим работы.
Аварийный режим работы характеризуется следующим состоянием:
а) все виртуальные машины продолжают работать в ЦОД (РЦОД) в случаях:
— сетевой изоляции сервера виртуализации в пределах ЦОД (РЦОД);
— сбоя виртуальной сети хранения данных между ЦОД и РЦОД;
— сбоя локальной сети между ЦОД и РЦОД.
б) все виртуальные машины автоматически перезапускаются на других узлах кластера в ЦОД (РЦОД) в случаях:
— сбоя одного или двух серверов виртуализации;
— отказа площадки ЦОД (РЦОД) при катастрофе (сбой всех серверов виртуализации).
Характеристики серверного оборудования
Сервер № 1
Intel Xeon Processor E5-2640 v2
Объём оперативной памяти
HP 300 ГБ 6G SAS 15K 2.5in SC ENT HDD
Сервер № 2
Intel Xeon Processor E5-2650
Объём оперативной памяти
HP 300 ГБ 6G SAS 15K 2.5in SC ENT HDD
Сервер № 3
Intel Xeon Processor X7560 8C
Тип оперативной памяти
IBM 8GB PC3-8500 CL7 ECC DDR3 1066 MHz LP RDIMM
Объём оперативной памяти
IBM 146 ГБ 6G SAS 15K 2.5in SFF SLIM HDD
Решение:
• Использовать имеющееся оборудование для создания подсистемы виртуализации.
• На базе того же оборудования и внутренних устройств хранения серверов создать виртуальную сеть хранения данных с функцией синхронной репликации томов с помощью программного обеспечения DataCore.
На каждом сервере виртуализации разворачивается виртуальный сервер — узел DataCore, к узлам DataCore дополнительно подключены виртуальные диски, созданные на локальных дисковых ресурсах серверов виртуализации. Данные диски объединяются в пулы дисковых ресурсов, на основе которых создаются зеркальные виртуальные диски. Диски зеркалируются между двумя узлами DataCore Virtual SAN — таким образом, на пуле дисковых ресурсов одного узла размещается «оригинал» диска, на втором — «зеркальная копия». Далее виртуальные диски презентуются серверам виртуализации (гипервизорам) либо виртуальным машинам напрямую.
Получается дёшево и сердито (коллеги подсказывают: конкурентное решение по цене) и без дополнительного железа. Кроме решения непосредственной задачи, сеть хранения данных получает массу полезного дополнительного функционала: повышение производительности, возможность интеграции с VMware, мгновенные снимки для всего объёма и так далее. При дальнейшем росте нужно только добавлять узлы виртуального кластера или апгредить имеющиеся.
Задача №2. Унифицированная система хранения (NAS/SAN).
Все начиналось с Windows Failover cluster для файлового сервера. Заказчику необходимо было сделать файловую шару для хранения документов — с высокой доступностью и резервным копированием данных и с почти мгновенным их восстановлением. Было принято решение строить кластер.
Из имеющегося оборудования у заказчика было два сервера Supermicro (к одному из которых подключён SAS JBOD). Дискового объёма в двух серверах более чем достаточно (около 10 ТБ на каждый сервер), однако для организации кластера необходим shared storage. Также планировалось иметь резервную копию данных, т. к. одна СХД — это единая точка отказа, желательно с CDP с покрытием рабочей недели. Данные должны быть доступны постоянно, максимальное время простоя — 30 минут (и то могут полететь головы). Стандартное решение включало в себя покупку СХД, ещё одного сервера для бэкапов.
Решение:
• ПО DataCore установлено на каждый сервер.
В архитектуре DataCore, Windows Failover Cluster может быть развернут без использования общего хранилища SAN (используя внутренние диски серверов) или с использованием DAS, JBOD или внешних СХД с полной реализацией архитектуры — DataCore Unified Storage (SAN & NAS), в полной мере используя возможности Windows Server 2012 и NFS & SMB (CIFS) и предоставляя сервис SAN внешним хостам. Такая архитектура и была в итоге развёрнута, и не используемый под файловый сервер объём дисков не был презентован как SAN для ESXi хостов.
Главный принцип
Основной принцип виртуализации СХД — с одной стороны, скрыть от потребителя весь бекэнд, с другой стороны, предоставить любому бэкенду единый реально конкурентный функционал.
Важные практические замечания именно по Датакоре
В одной из задач у нас была организация DMZ-сегмента крупной компании. Для экономии хранения и оптимизация доступа к локальному хранилищу поставили как раз DC. Общий SAN ядро с DMZ не делили, поэтому надо было бы либо покупать СХД и ещё одну железку типа файрволла с навесками для безопасного доступа внутрь, либо шевелить извилинами. Мы объединили 3 хоста виртуализации в единое пространство плюс оптимизировали доступ. Получилось дешёво и быстро.
В ещё одной задаче у нас была оптимизация доступа под SQL. Там мы смогли использовать старые медленные хранилища. Запись благодаря кэшу DC пошла быстрее в десятки раз, чем напрямую.
Есть полезный для некоторых ситуаций RAID Striping (можно строить программные RAID0 и RAID1, даже если подключённый DAS этого не умеет).
Хорошие отчёты — визуальные и статистические инструменты предоставления данных о всевозможных параметрах производительности с указанием «узких» мест.
QoS Control даёт возможность СУБД и критическим приложением работать быстрее, устанавливая ограничения на трафик ввода/вывода для менее важных нагрузок.
Я вырубал узлы на тестах по питанию (в разумных пределах, сохраняя необходимое количество узлов для корректного восстановления), но не смог поймать коррапты. Synchronous Mirroring & Auto Failover — есть синхронная репликация и механизмы автоматического и настраиваемого восстановления после сбоев. Функция самолечения дисковых пулов такая: если физический диск в пуле выходит из строя или помечен для замены, DataCore автоматически восстанавливает пул на доступных ресурсах. Плюс журнал изменений на диске с возможностью восстановиться из любого состояния или из любого времени. Плановая замена дисков, естественно, делается без перерыва в работе. Как обычно, данные размазывают между другими инстансами, а потом при появлении первой возможности том «заползает» и на новый диск. Примерно по похожему принципу делается миграция между ЦОДами, только «замена дисков» носит массовый характер.
Есть Virtual Disk Migration — простая и эффективная миграция данных с физических ресурсов в виртуальные и обратно. ПричЁм без остановки приложений. есть возможность всем подключиться к живой инсталляции и потрогать консоль своими руками.