какая главная проблема сложность наличия множества разных систем хранения данных в организации
Проблема систем хранения – цена и совместимость
Несмотря на то что системы хранения данных и хранилища данных, строго говоря, совершенно разные понятия, их совместное применение на практике не редкость. А на рынке оборудования для хранения данных уже можно подобрать устройство, удовлетворяющее практически любым требованиям. Тем не менее два вопроса — цена оборудования и его совместимость с продуктами других производителей — остаются нерешенными, считает Андрей Веневцев, начальник управления вычислительных систем и телекоммуникаций банка «Союз».
Андрей Веневцев,
начальник управления вычислительных систем и телекоммуникаций банка «Союз»
— Какое оборудование для хранения данных используется в вашем банке? Чем определялся его выбор? Приходилось ли его дорабатывать с учетом специфики требований банка?
— В нашем банке системы хранения данных применяются уже давно и успешно. Корпоративным стандартом банка является оборудование производства компании EMC. Сейчас в связи с возросшими потребностями у нас идет внедрение решения Hi-end уровня EMC V-MAX.
Основным критерием выбора данного производителя являлось соотношение цена/качество. Кроме того, привлекательно выглядит стратегия, объявленная этим поставщиком, — ориентация всей деятельности компании на сектор хранения, резервирования и обработки данных, обеспечение эффективности решения этих вопросов.
Главными преимуществами, которые позволяет реализовать любая система хранения, является гибкость в управлении ресурсами хранения и обеспечение основы для использования таких отказоустойчивых технологий, как Microsoft Cluster Service, VMware vMotion, High Availability, Fault Tolerance и др.
Кроме того, у нас средствами систем хранения реализовано онлайновое копирование данных между основным и резервным ЦОД банка. В случае EMC V-MAX эти преимущества дополняются исключительно высокой производительностью и надежностью оборудования.
Теперь расскажу немного о хранилище данных банка. Оно было принято в промышленную эксплуатацию в 2008 году. Основная задача, решаемая этим проектом, состояла в поддержке формировании управленческой отчетности банка и построения единого хранилища данных банка. Это заказная разработка на базе Oracle Financial Services. В качестве платформы централизованного хранилища финансово-аналитических данных в этом решении используется Oracle Financial Data Manager — ключевой компонент OFSA, обеспечивающий создание и ведение хранилища данных. В нем содержатся как агрегированные финансовые данные, так и детальные данные по всем выданным кредитам, привлеченным депозитам и другим финансовым инструментам банка.
Выбор OFSA производился по результатам анализа в рамках разработки системной архитектуры с привлечением одной из ведущих компаний-интеграторов. Основными критериями были функциональность и стоимость решения.
Наполнение хранилища производится централизованно, оно консолидирует финансовые данные большинства учетных систем во всех филиалах банка. Для извлечения, преобразования и загрузки данных в хранилище используются модули, которые являются специфическими для систем-источников.
В настоящий момент данные хранилища используются при подготовке управленческой отчетности и в ряде бизнес-подразделений банка.
— Какие наиболее типичные проблемы с внедрением или сопровождением хранилища данных и систем хранения данных существуют сейчас у банков, на ваш взгляд?
— Как мне кажется, на этапе внедрения любого хранилища данных есть две основные проблемы. Первая — это постановка задачи по аналитике и отчетам. Так как внедрение хранилища — процесс, который может длиться довольно долго, зачастую бывает, что коренным образом меняется не только постановка задачи, но и собственно люди, которые ее ставят и формулируют. А на практике структура и состав результирующих документов, получаемых из системы, оказывает серьезное влияние на набор требуемых данных и структуру витрин данных. Поэтому в процессе внедрения изменение этих параметров весьма нежелательно — это приводит к удорожанию проекта и срыву сроков
Так как консолидация данных на одном устройстве повышает риск их утраты или потери доступа к ним, лучше сразу заботиться о дублировании данных на нескольких системах хранения
Проблем с внедрением систем хранения при грамотном проектировании быть не должно. Конечно, есть различные технические трудности, но они преодолеваются на этапе проектирования. Однако есть несколько ключевых моментов, на которые следует обращать внимание.
Для достижения эффекта от системы хранения необходимо сразу проектировать всю инфраструктуру хранения данных, а не пытаться внедрить отдельно взятый экземпляр. Если отсутствуют средства, внедрение можно проводить этапами.
Необходимо сразу позаботиться об оптических линиях связи и портах в Fiber Chanel-коммутаторах, они должны быть в достаточном количестве. После появления централизованной системы хранения к ней будет подключено больше серверов, чем запланировано заранее, и к этому надо быть готовым.
Так как консолидация данных на одном устройстве повышает риск их утраты или риск потери к ним доступа в случае выхода этого устройства из строя, необходимо сразу заботиться о дублировании данных на нескольких системах хранения. Если у организации несколько ЦОДов в различных зданиях, лучше всего распределить системы хранения между ними.
— Как бы вы определили основные претензии банков к разработчикам существующего на рынке оборудования для хранения данных?
— Как банки, так и остальные клиенты производителей систем хранения выдвигают две основные претензии. Это высокая стоимость систем хранения и компонентов сетей хранения — она превышает стоимость аналогичных устройств локальных вычислительных сетей почти на порядок. И вторая претензия — это несовместимость между оборудованием разных производителей.
Нередко можно оказаться в ситуации, когда система хранения и коммутатор не работают вместе — везде, кроме сетей хранения. Это нонсенс.
Несмотря на то что производители систем хранения постоянно дорабатывают свои системы в соответствии с запросами своих клиентов, эти два вопроса — цена оборудования и совместимость его с продуктами других производителей и между собой — остаются постоянными. Решение второго вопроса, скорее всего, приведет и к решению первого. Причем, как мне кажется, в выигрыше останутся все, так как исчезнут основные препятствия на пути массового применения сетей хранения.
К производителям хранилищ данных четко выраженных по отрасли претензий сформулировать не получается. Дело в том, что хранилища данных не продаются «из коробки» и основные вопросы возникают непосредственно в общении между банком и компанией, осуществляющей внедрение.
— Заметны ли какие-то интересные изменения на рынке этих систем?
— Безусловно, изменения на рынке есть. IT-сообщество, пережив бум строительства хранилищ данных по поводу и без повода, наконец стало понимать, что именно скрывается за этим термином. Кроме того, на рынке наконец появились компании, которые отводят в своей деятельности внедрению хранилищ данных значительное место.
— Ваша рекомендация коллегам — что обязательно нужно учесть при поддержке функционирования системы хранения данных и хранилища в случае, когда идет перестройка всей IT-инфраструктуры банка?
— В случае с системами хранения данных я бы рекомендовал следующее. Не полагайтесь только на надежность оборудования. Необходимо выполнять весь перечень мероприятий по резервированию и резервному копированию данных.
При перестройке инфраструктуры придерживайтесь принципов преемственности, это позволит избежать многих рисков и сильно облегчит работу по миграции данных.
Никогда не производите серьезных изменений без предварительного тестирования и проработки технических деталей, оформленных документально, — это позволит минимизировать риск ошибки персонала.
Всегда резервируйте системы хранения, на которых хранятся данные промышленных приложений, системами, аналогичными по функционалу и производительности. Только так можно избежать простоев или потерь данных.
Для хранилищ данных очень важны следующие действия. Проверяйте корректность загруженных в хранилище данных — наличие ошибок в данных приведет к ошибкам в отчетности и подорвет доверие бизнес-пользователей к этой технологии.
Проводите регулярное резервное копирование хранилища данных. Повторная загрузка данных — это весьма трудоемкий и долгий процесс.
Осуществляйте доработки, связанные с хранилищем данных, только при наличии согласованных со стороны руководства бизнес-подразделений подробных заданий. Хранилище данных не предназначено для оперативной отчетности, которую можно получить из отдельных учетных систем.
Жестко отфильтровывайте отчеты и задания на разработку — необходимо сформулировать критерии отбора задач для хранилища данных и реализовывать задания, не подходящие под эти критерии, в локальных учетных системах.
Вам надо по-другому работать с наличкой. Кого прижмут налоговики и банки? Забирайте запись, пожалуй, лучшего вебинара «Клерка»: «Как теперь будут контролировать наличку. 115-ФЗ в 2021 году ».
Только до завтра можно забрать запись со скидкой 20%. Программу вебинара смотрите здесь
Хранение данных. Или что такое NAS, SAN и прочие умные сокращения простыми словами
TL;DR: Вводная статья с описанием разных вариантов хранения данных. Будут рассмотрены принципы, описаны преимущества и недостатки, а также предпочтительные варианты использования.
Зачем это все?
Хранение данных — одно из важнейших направлений развития компьютеров, возникшее после появления энергонезависимых запоминающих устройств. Системы хранения данных разных масштабов применяются повсеместно: в банках, магазинах, предприятиях. По мере роста требований к хранимым данным растет сложность хранилищ данных.
Надежно хранить данные в больших объемах, а также выдерживать отказы физических носителей — весьма интересная и сложная инженерная задача.
Хранение данных
Под хранением обычно понимают запись данных на некоторые накопители данных, с целью их (данных) дальнейшего использования. Опустим исторические варианты организации хранения, рассмотрим подробнее классификацию систем хранения по разным критериям. Я выбрал следующие критерии для классификации: по способу подключения, по типу используемых носителей, по форме хранения данных, по реализации.
По способу подключения есть следующие варианты:
подключение дисков в сервере
дисковая полка, подключаемая по FC
По типу используемых накопителей возможно выделить:
Если рассматривать форму хранения данных, то явно выделяются следующие:
По реализации достаточно сложно провести четкие границы, однако можно отметить:
RAID контроллер от компании Fujitsu
пример организации LVM с шифрованием и избыточностью в виртуальной машине Linux в облаке Azure
Давайте рассмотрим более детально некоторые технологии, их достоинства и недостатки.
Direct Attached Storage — это исторически первый вариант подключения носителей, применяемый до сих пор. Накопитель, с точки зрения компьютера, в котором он установлен, используется монопольно, обращение с накопителем происходит поблочно, обеспечивая максимальную скорость обмена данными с накопителем с минимальными задержками. Также это наиболее дешевый вариант организации системы хранения данных, однако не лишенный своих недостатков. К примеру если нужно организовать хранение данных предприятия на нескольких серверах, то такой способ организации не позволяет совместное использование дисков разных серверов между собой, так что система хранения данных будет не оптимальной: некоторые сервера будут испытывать недостаток дискового пространства, другие же — не будут полностью его утилизировать:
Конфигурации систем с единственным накопителем применяются чаще всего для нетребовательных нагрузок, обычно для домашнего применения. Для профессиональных целей, а также промышленного применения чаще всего используется несколько накопителей, объединенных в RAID-массив программно, либо с помощью аппаратной карты RAID для достижения отказоустойчивости и\или более высокой скорости работы, чем единичный накопитель. Также есть возможность организации кэширования наиболее часто используемых данных на более быстром, но менее емком твердотельном накопителе для достижения и большой емкости и большой скорости работы дисковой подсистемы компьютера.
Storage area network, она же сеть хранения данных, является технологией организации системы хранения данных с использованием выделенной сети, позволяя таким образом подключать диски к серверам с использованием специализированного оборудования. Так решается вопрос с утилизацией дискового пространства серверами, а также устраняются точки отказа, неизбежно присутствующие в системах хранения данных на основе DAS. Сеть хранения данных чаще всего использует технологию Fibre Channel, однако явной привязки к технологии передачи данных — нет. Накопители используются в блочном режиме, для общения с накопителями используются протоколы SCSI и NVMe, инкапсулируемые в кадры FC, либо в стандартные пакеты TCP, например в случае использования SAN на основе iSCSI.
Давайте разберем более детально устройство SAN, для этого логически разделим ее на две важных части, сервера с HBA и дисковые полки, как оконечные устройства, а также коммутаторы (в больших системах — маршрутизаторы) и кабели, как средства построения сети. HBA — специализированный контроллер, размещаемый в сервере, подключаемом к SAN. Через этот контроллер сервер будет «видеть» диски, размещаемые в дисковых полках. Сервера и дисковые полки не обязательно должны размещаться рядом, хотя для достижения высокой производительности и малых задержек это рекомендуется. Сервера и полки подключаются к коммутатору, который организует общую среду передачи данных. Коммутаторы могут также соединяться с собой с помощью межкоммутаторных соединений, совокупность всех коммутаторов и их соединений называется фабрикой. Есть разные варианты реализации фабрики, я не буду тут останавливаться подробно. Для отказоустойчивости рекомендуется подключать минимум две фабрики к каждому HBA в сервере (иногда ставят несколько HBA) и к каждой дисковой полке, чтобы коммутаторы не стали точкой отказа SAN.
Недостатками такой системы являются большая стоимость и сложность, поскольку для обеспечения отказоустойчивости требуется обеспечить несколько путей доступа (multipath) серверов к дисковым полкам, а значит, как минимум, задублировать фабрики. Также в силу физических ограничений (скорость света в общем и емкость передачи данных в информационной матрице коммутаторов в частности) хоть и существует возможность неограниченного подключения устройств между собой, на практике чаще всего есть ограничения по числу соединений (в том числе и между коммутаторами), числу дисковых полок и тому подобное.
Network attached storage, или сетевое файловое хранилище, представляет дисковые ресурсы в виде файлов (или объектов) с использованием сетевых протоколов, например NFS, SMB и прочих. Принципиально базируется на DAS, но ключевым отличием является предоставление общего файлового доступа. Так как работа ведется по сети — сама система хранения может быть сколько угодно далеко от потребителей (в разумных пределах разумеется), но это же является и недостатком в случае организации на предприятиях или в датацентрах, поскольку для работы утилизируется полоса пропускания основной сети — что, однако, может быть нивелировано с использованием выделенных сетевых карт для доступа к NAS. Также по сравнению с SAN упрощается работа клиентов, поскольку сервер NAS берет на себя все вопросы по общему доступу и т.п.
Unified storage
Универсальные системы, позволяющие совмещать в себе как функции NAS так и SAN. Чаще всего по реализации это SAN, в которой есть возможность активировать файловый доступ к дисковому пространству. Для этого устанавливаются дополнительные сетевые карты (или используются уже существующие, если SAN построена на их основе), после чего создается файловая система на некотором блочном устройстве — и уже она раздается по сети клиентам через некоторый файловый протокол, например NFS.
Software-defined storage — программно определяемое хранилище данных, основанное на DAS, при котором дисковые подсистемы нескольких серверов логически объединяются между собой в кластер, который дает своим клиентам доступ к общему дисковому пространству.
Наиболее яркими представителями являются GlusterFS и Ceph, но также подобные вещи можно сделать и традиционными средствами (например на основе LVM2, программной реализации iSCSI и NFS).
N.B. редактора: У вас есть возможность изучить технологию сетевого хранилища Ceph, чтобы использовать в своих проектах для повышения отказоустойчивости, на нашем практическим курсе по Ceph. В начале курса вы получите системные знания по базовым понятиям и терминам, а по окончании научитесь полноценно устанавливать, настраивать и управлять Ceph. Детали и полная программа курса здесь.
Пример SDS на основе GlusterFS
Из преимуществ SDS — можно построить отказоустойчивую производительную реплицируемую систему хранения данных с использованием обычного, возможно даже устаревшего оборудования. Если убрать зависимость от основной сети, то есть добавить выделенные сетевые карты для работы SDS, то получается решение с преимуществами больших SAN\NAS, но без присущих им недостатков. Я считаю, что за подобными системами — будущее, особенно с учетом того, что быстрая сетевая инфраструктура более универсальная (ее можно использовать и для других целей), а также дешевеет гораздо быстрее, чем специализированное оборудование для построения SAN. Недостатком можно назвать увеличение сложности по сравнению с обычным NAS, а также излишней перегруженностью (нужно больше оборудования) в условиях малых систем хранения данных.
Гиперконвергентные системы
Подавляющее большинство систем хранения данных используется для организации дисков виртуальных машин, при использовании SAN неизбежно происходит удорожание инфраструктуры. Но если объединить дисковые системы серверов с помощью SDS, а процессорные ресурсы и оперативную память с помощью гипервизоров отдавать виртуальным машинам, использующим дисковые ресурсы этой SDS — получится неплохо сэкономить. Такой подход с тесной интеграцией хранилища совместно с другими ресурсами называется гиперконвергентностью. Ключевой особенностью тут является способность почти бесконечного роста при нехватке ресурсов, поскольку если не хватает ресурсов, достаточно добавить еще один сервер с дисками к общей системе, чтобы нарастить ее. На практике обычно есть ограничения, но в целом наращивать получается гораздо проще, чем чистую SAN. Недостатком является обычно достаточно высокая стоимость подобных решений, но в целом совокупная стоимость владения обычно снижается.
Облака и эфемерные хранилища
Логическим продолжением перехода на виртуализацию является запуск сервисов в облаках. В предельном случае сервисы разбиваются на функции, запускаемые по требованию (бессерверные вычисления, serverless). Важной особенностью тут является отсутствие состояния, то есть сервисы запускаются по требованию и потенциально могут быть запущены столько экземпляров приложения, сколько требуется для текущей нагрузки. Большинство поставщиков (GCP, Azure, Amazon и прочие) облачных решений предлагают также и доступ к хранилищам, включая файловые и блочные, а также объектные. Некоторые предлагают дополнительно облачные базы, так что приложение, рассчитанное на запуск в таком облаке, легко может работать с подобными системами хранения данных. Для того, чтобы все работало, достаточно оплатить вовремя эти услуги, для небольших приложений поставщики вообще предлагают бесплатное использование ресурсов в течение некоторого срока, либо вообще навсегда.
Из недостатков: могут заблокировать аккаунт, на котором все работает, что может привести к простоям в работе. Также могут быть проблемы со связностью и\или доступностью таких сервисов по сети, поскольку такие хранилища полностью зависят от корректной и правильной работы глобальной сети.
Заключение
Надеюсь, статья была полезной не только новичкам. Предлагаю обсудить в комментариях дополнительные возможности систем хранения данных, написать о своем опыте построения систем хранения данных.
Большой ликбез: распределённые системы хранения данных в практической привязке для админов среднего и крупного бизнеса
Современные сети и дата-центры бодро шагают к полной и тотальной программно-определяемой схеме, когда фактически неважно, какое железо вы напихаете внутрь, всё будет на софте. У сотовых операторов это началось с того, что им не хотелось ставить по 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 — простая и эффективная миграция данных с физических ресурсов в виртуальные и обратно. ПричЁм без остановки приложений. есть возможность всем подключиться к живой инсталляции и потрогать консоль своими руками.