Подписаться
Читать в телеграм
Как правильно управлять критичными данными и защититься от их потери?
Основные технологии, применяемые для оптимизации времени восстановления при сбоях?
Что умеют решения NetApp?
В успешных компаниях количество данных постоянно увеличивается. С ростом числа клиентов множится документооборот и объем переписки. Для хранения информации компания докупает дисковые емкости, затем задумывается о ее сохранности и доступности, строит второй ЦОД, устанавливает систему резервного копирования. Но со временем данных становится так много, что классические подходы перестают работать и для их эффективной защиты (и возможности восстановления) нужно что-то придумывать, зачастую на стыке функционала различных продуктов. Сегодня мы и хотим поговорить о том, что успели придумать за последнее время производители ПО и оборудования для хранения данных и как наиболее эффективно использовать новые технологии в СХД.
Забегая вперед, скажем, что с помощью правильной архитектуры хранения можно не только успешно решить вопросы защиты информации от потери (в том числе уберечься от пресловутых вирусов-шифровальщиков), но и с большой экономией времени и денег развернуть тестовые среды (буквально за минуты, не занимая при этом практически никакого дополнительного пространства), а также обеспечить такую отказоустойчивость, когда даже потеря целой площадки никак не скажется на доступности критичных данных. Все это — не технологическая утопия, а вполне реальные успешные проекты, уже реализованные у наших заказчиков.
В чем же существенная разница в управлении большими объемами данных и «обычными» объемами информации (100–200 ТБ)? Если отвечать кратко — время. Продолжительность любых операций для объемов информации, например, 500 ТБ в 5 раз больше, чем длительность тех же операций для 100 ТБ. Это и миграция, и репликация, и резервное копирование, и восстановление. Скорость восстановления данных резервного копирования с самых быстрых и дорогих устройств на рынке составляет порядка 50 ТБ/ч при оптимальных условиях (много потоков, много быстрых интерфейсов и т.д.). И полная перезапись информации для СХД в 500 ТБ может занять 10 часов и более — например, в случае если данные зашифровал вирус или с вашей системой что-то случилось. Но производители не стоят на месте и давно предлагают решения для таких ситуаций. Кратко перечислим основные технологии, применяемые для оптимизации времени восстановления в случае сбоев.
Защита от аппаратных сбоев или выхода из строя оборудования и инфраструктуры:
- Связь систем хранения на двух площадках с помощью растянутого метрокластера с единым пространством данных (например, хранилище для виртуальных машин). Данные записываются синхронно, сразу на две СХД, а том доступен на запись с обеих площадок. Польза от метрокластера очевидна: в случае множественных сбоев оборудования, потери СХД или даже площадки целиком, все данные сохраняются в том же объеме на второй площадке, при этом прерывания доступа не происходит. Единственное ограничение: системы должны находиться достаточно близко друг от друга, так как расстояние напрямую влияет на время прохождения сигнала и, соответственно, время отклика системы при записи данных. Для бизнес-критичных систем оптимальное расстояние — до 30 км, но, в зависимости от производителя, расстояния могут достигать и 700 км. В основном поддерживаются только блочные протоколы доступа, но некоторые производители (например, NetApp) реализовали метрокластер и для файлового доступа.
Восстановление в случае повреждения или удаления данных:
- Аппаратные мгновенные снимки (snapshots). Эта технология отнюдь не нова, но до массового появления систем хранения на быстрых флеш-дисках не пользовалась широкой популярностью, так как даже сейчас ее применение может вызывать серьезное падение производительности СХД многих вендоров. Постоянно растущие объемы систем хранения данных существенно увеличили спрос на подобные технологии, ведь данные могут быть защищены или клонированы за секунды, вне зависимости от их размера. Однако даже сейчас многие спрашивают, как и зачем это использовать. Так как снэпшоты — основа для множества полезных инструментов, рассмотрим эту технологию подробнее чуть дальше.
- Репликация мгновенных снимков на другую СХД позволяет использовать для более длительного хранения сотен или тысяч мгновенных снимков более дешевые конфигурации СХД (например, на более медленных флеш-дисках или даже шпинделях), а также в качестве бонуса иметь простой сценарий для восстановления после катастрофы. Данное решение является альтернативой классическому копированию данных целиком между системами, однако у этой технологии есть и ограничения: оба массива должны быть от одного производителя и поддерживать такую репликацию, что реализовано не у всех вендоров.
Джентльменский набор СХД
Кроме того, не стоит забывать и о других полезных технологиях, которые, на наш взгляд, необходимо иметь в хорошей СХД в 2021 г:
- Для любых нагрузок в продуктиве имеет смысл использовать массивы, строящиеся целиком на твердотельных дисках (all flash). По цене они все еще немного дороже «обычных» шпиндельных дисков, но по производительности превосходят их в десятки раз. А с учетом технологий оптимизации пространства, такие массивы зачастую обходятся дешевле, чем их шпиндельные или гибридные собратья с аналогичной емкостью. Не будем забывать и про компактность: сейчас в 2–3 юнита СХД стандартного размера можно уместить несколько сотен терабайт данных. Шпиндельные и гибридные системы таких объемов занимали бы минимум половину стойки.
- Новые протоколы работы с твердотельными дисками (NVMe). По результатам различных тестов производителей, их применение сокращает время отклика (особенно если весь путь от сервера до дисков построен с поддержкой этого протокола), что позволяет «выжать» из массива еще больше производительности.
- Дедупликация и компрессия данных с хорошими коэффициентами и без потери производительности. Помогает экономить деньги, удешевляя итоговую стоимость за терабайт хранимой информации. Если эти технологии влияют на производительность, придется выбирать между скоростью и ценой, поэтому стоит обращать внимание на то, как именно работает оптимизация пространства в вашей СХД. На рынке есть варианты без таких компромиссов.
- Поддержка различных типов доступа на одном массиве. Сейчас практически все производители предлагают универсальные СХД с блочным и файловым доступом, но у некоторых из них присутствуют серьезные ограничения, вплоть до использования разного оборудования для разных типов. А новинкой сезона стало добавление компанией NetApp к этому набору еще и объектного доступа в одной «железке». Теперь заказчики могут выделить отдельную область на СХД, куда можно складывать данные по протоколу S3, в дополнение к имеющимся NVMe-FC, FC, iSCSI, NFS, CIFS, не приобретая для этих целей отдельных хранилищ. Этот функционал добавлен в новую версию операционной системы Data ONTAP, работающую на массивах серии FAS и AFF, и доступен пользователям даже прошлых поколений массивов при условии обновления прошивки.
Все перечисленные технологии, с нашей точки зрения, выводят использование системы хранения данных на новый уровень и позволяют решать круг задач более широкий, чем простое хранение данных. Современные СХД даже помогают строить частные и гибридные облака, предоставляя удобные инструменты управления и автоматизации, а также облегчая бесшовный переход и достижение совместимости между физическими устройствами в ЦОДе и программными реализациями в облаке.
Идеальное управление данными
Современную ИТ-инфраструктуру для работы с большими объемами информации целесообразно строить с учетом возможности интеграции между различными системами. И в этом процессе система хранения данных может сыграть центральную роль.
Представьте себе такую ситуацию: у вас есть важные базы данных на несколько сотен терабайт, требующие колоссальной производительности от оборудования. При этом окно резервного копирования должно быть минимальным, так как классические СРК во время своей работы нагружают и сервер, и СХД и это влияет на время отклика ваших бизнес-систем. А требования по непрерывности бизнеса таковы, что и потери данных (показатель RPO), и время восстановления сервисов при сбое или аварии (RTO) должны быть минимальными (в идеале равными нулю). Параллельно необходимо держать несколько копий этих баз для нужд тестирования и разработки, обеспечивая минимальное потребление места и ресурсов. Существуют ли простые решения для таких комплексных ситуаций? Наш ответ — да. И большинство решений уже применяется в современных СХД ведущих производителей. Для реализации такой «идеальной» схемы управления большими объемами критичных данных важны два фактора: использование мощной СХД, обладающей всем функционалом, о котором говорилось выше (только твердотельные диски, включенная дедупликация и компрессия, аппаратные снимки без влияния на производительность и т.д.), а также современного ПО СРК, которое умеет управлять аппаратными снимками и репликацией на уровне СХД и поддерживает средства автоматизации.
Сама схема может выглядеть следующим образом:
1. Продуктивные СХД кластеризованы и (в идеале) находятся на разных площадках. При этом схема защиты данных может быть реализована несколькими способами — от метрокластера, растянутого на аппаратном уровне средствами самих систем хранения, до программной репликации средствами ПО (например, Oracle или Veritas Infoscale). Как говорилось выше, это позволит пережить аппаратные сбои оборудования и даже потерю одной из площадок, но сохранить при этом постоянный доступ к данным.
2. На любой из площадок система резервного копирования на продуктивной СХД делает консистентный аппаратный снимок — снэпшот. Его создание занимает от нескольких секунд до нескольких минут (в зависимости от конкретного приложения) и не вызывает остановки или замедления сервиса, а данные могут быть восстановлены как полностью (для отката такого снимка на СХД требуется от нескольких секунд до нескольких часов — в зависимости от технологии, используемой производителем СХД), так и гранулярно — можно восстановить любые объекты, которые были на этом томе. Далее аппаратный снимок может быть использован для создания второй резервной копии на другой СХД с более длительным сроком хранения (оптимально — с помощью аппаратной репликации снэпшотов между системами). Например, можно хранить снимки для оперативного восстановления на основной СХД в течение 14 дней, а на вторичной СХД сроки хранения снимков или копий могут быть продлены до месяцев или даже года. Так как располагать продуктивные данные и их резервные копии только на одной СХД небезопасно, снэпшоты в любом случае должны быть скопированы или отреплицированы на вторичное хранилище.
При использовании этих технологий окно резервного копирования будет складываться только из времени создания первого снэпшота (от секунд до минут), остальные действия будут происходить без влияния на продуктив. При этом время прохождения задач (и, соответственно, окно резервного копирования) не будет зависеть от объема данных. В ряде случаев это позволяет совсем отказаться от понятия «окно резервного копирования» и делать копии в произвольное время с любой частотой, не привязываясь к графику нагрузки систем.
3. Любой аппаратный снимок, помимо применения в качестве точки восстановления и основы для второй копии данных, может служить источником для создания клонов базы для тестирования и разработки. ПО СРК (например, Commvault или NetApp SnapCenter) помогает автоматизировать этот процесс и само создает такие клоны из ранее сделанного снэпшота. А отдельная «магия» процесса заключается в том, что сам клон аппаратного снимка на СХД не потребует дополнительного объема для хранения: место будут занимать только изменения и новые данные, записанные разработчиками. Это позволяет держать десятки копий базы, оставаясь в рамках объемов продуктива, и получать коэффициенты дедупликации до 20 к 1 и даже выше.
Таким образом, используя первичные и вторичные системы хранения данных с поддержкой таких технологий от одного производителя, мы получаем возможность построить полностью интегрированную систему, решающую задачи как защиты данных, так и автоматизации тестовых сред. Широкое применение мгновенных снимков позволяет разорвать зависимость между объемами данных и временем, потраченным на обеспечение защиты данных или их клонирование. И все это не приведет к кратному увеличению требуемых объемов хранения, так как место будут занимать только уникальные данные, которые при этом будут сжаты и дедуплицированы.
Аналогичные сценарии можно построить и для виртуальных машин. В VMware 7.0 и выше есть технология native snaphots — интеграция с аппаратными снимками производителей СХД (например, NetApp). Она позволяет передать управление такими снимками на уровень хранения, что решит старые проблемы замедления операций ввода-вывода виртуальной среды и длительных слияний файлов при использовании множества программных снимков VMware. Таким образом, резервные копии даже 1000 виртуальных машин любого объема могут быть созданы за несколько минут (время, требуемое на подготовку их операционных систем для перехода в консистентное состояние). Подобная возможность позволяет на порядки сократить любое окно резервного копирования и восстановления и не ориентироваться на объемы виртуальных машин.
В связи с актуальностью угрозы со стороны вирусов-шифровальщиков, сгенерированных для атаки на конкретную компанию, возможность быстрого восстановления больших объемов данных важна как никогда, а дополнительные функции безопасности, разработанные производителями СХД за последние пару лет, еще больше усиливают защиту.
Имея вторичную СХД с репликами мгновенных снимков продуктивных систем, расположенную на другой площадке или в публичном облаке, можно организовать простой процесс защиты от катастроф (DRP), так как любая система может быть запущена непосредственно со вторичной СХД (быстрее всего — путем клонирования резервной копии мгновенного снимка) без необходимости выделения дополнительного дискового пространства для восстановления резервной копии.
Если раньше использование дисковых хранилищ на твердотельных накопителях для хранения резервных копий казалось излишеством, то сейчас, в 2021 г., мы уже делаем проекты с использованием нескольких слоев хранения вторичных копий, в зависимости от степени критичности систем. Так как по стоимости SSD не сильно отличается от HDD, сокращение времени обслуживания критичных данных окупает эти затраты. Расширение использования SSD в подобных сценариях — тренд ближайшего будущего. Такое применение становится востребованным в том числе и потому, что большинство систем резервного копирования научились работать с хранилищем резервных копий напрямую, как с «запасной СХД», в случае отказа основных систем. Именно для этого и имеет смысл покупать под бэкап быстрые хранилища, особенно если нет возможности реализовать схему с интеграциями всех СХД в единую систему защиты, как в примере выше.
Технологии NetApp
NetApp — одна из немногих компаний, которые производят СХД, позволяющие реализовать все эти современные схемы работы с данными. Она известна на рынке как технологически инновационный производитель решений для хранения данных, и многолетнее лидерство в квадранте Gartner — подтверждение этого. Тестируя для наших заказчиков новые подходы и технологии защиты данных на разных СХД, мы пришли к выводу, что не так много вендоров на рынке отвечают вышеизложенным требованиям. А концепция работы систем NetApp нам понравилась своей полной готовностью к реализации новых подходов. Помимо технологичности ее решений, к достоинствам NetApp можно отнести наличие широкой линейки массивов на любой вкус и кошелек, развитую систему поддержки автоматизации, большое количество написанных вендором и сообществом скриптов интеграции для Kubernetes и Ansible. Системы хранения данных NetApp масштабируются как вертикально (от десятков до тысяч дисков на одну пару контроллеров), так и горизонтально (до 24 контроллеров; можно объединять контроллеры разных моделей и поколений с разными типами дисков в одной СХД). Операционную систему ONTAP, используемую во всех моделях массивов NetApp FAS и AFF, можно использовать как внутри СХД NetApp, так и в гибридных и публичных облаках в виде виртуальных машин и аплайнсов. Не нужно забывать и про S3-хранилища, на которых можно хранить как данные, так и резервные копии и при этом обеспечивать бесшовную интеграцию не только с облаком (у любых провайдеров доступны программные хранилища от NetApp, в том числе с поддержкой протокола S3), но и с локальной СРК. Такой подход в целом обеспечивает большую гибкость при построении отказоустойчивой и при этом простой и совместимой по компонентам инфраструктуры гибридных и частных облаков. Стоит также отметить, что оптимизация пространства в виде дедупликации и сжатия доступна в NetApp как на массивах all flash, так и на гибридных массивах с обычными шпиндельными дисками.
ПО интеграции с VMware (VMware Plugin), Kubernetes (Trident, Astra) позволяет предоставить поддержку со стороны СХД процессов выделения и контроля дискового пространства для виртуальных машин и контейнеров. Так как еще одним востребованным функционалом в современной СХД является поддержка процессов автоматизации и практик DevOps (CI/CD), NetApp обеспечивает такие функции не только через интеграцию в среды виртуализации и управления контейнерами, но и путем использования REST API и готовых Ansible plugins.
Описанная выше схема защиты и использования данных могла бы выглядеть в графике вот так (на примере СХД от NetApp):
Обойдемся без «костылей» и изоленты
Давайте подведем итоги. Выше мы рассмотрели несколько новых и перспективных, с нашей точки зрения, подходов к защите данных и совмещению различных технологий для решения проблем больших данных. По отдельности они существовали и раньше, но теперь, с развитием технологий хранения данных и достижения производителями определенной зрелости, понемногу становится возможным интегрировать их в едином ландшафте и архитектуре без использования «костылей» и изоленты для интеграции различных компонентов. Мы считаем, что будущее за комплексным подходом к управлению данными и гибридными инфраструктурами, когда бизнес-приложения и их данные, защищенные и интегрированные на всех этапах существования, могут свободно перемещаться между различными типами носителей как в собственном ЦОДе, так и в облаках. Это позволит компаниям гибко формировать подход к ИТ-инфраструктуре, обеспечивая наилучшее использование инвестиций.
Не менее интересно и то, что от угроз информационной безопасности, которые всегда были зоной ответственности ИБ-команд, теперь можно защищаться и с помощью правильно построенной инфраструктуры. За последние год-два производители оборудования и ПО разработали для своих решений множество функций, использование которых как упростит защиту, так и выручит при необходимости полного восстановления данных. А система резервного копирования становится лишь частью более глобальных планов по защите от катастроф (DRP — disaster recovery plan) и по обеспечению непрерывности бизнеса (BCP), которые будут включать в себя и другие средства, компоненты и методики комплексной защиты данных.
У современных систем хранения данных, как правило, достаточно высокая производительность — на уровне сотен тысяч операций ввода вывода в секунду (IOPS), но и здесь есть нюансы. У ряда вендоров технологии реализованы оптимально, и включение дополнительного функционала (снэпшоты, дедупликация и т.д.) не влияет на производительность — то есть вся мощь системы используется для продуктивных нагрузок. У других же производителей эти IOPS «расходуются» на дополнительный функционал, что в итоге (при включении всех функций) дает на выходе производительность в несколько раз ниже. Другими словами, при построении сложных архитектур выбор производителя имеет значение.
Таким образом, роль системы хранения данных за последнее время сильно возросла. Сложность перешла на уровень ПО (прошивки массива) и интеграции СХД с экосистемой других инфраструктурных продуктов. Использование последних наработок в этой области дает множество преимуществ, однако требует детального проектирования и большой экспертизы при внедрении.
