Теперь, когда мы знаем основные компоненты компьютера и разбираемся в типах накопителей, можно перейти к самому важному вопросу: что же такое СХД и чем она отличается от обычного компьютера.
В момент, когда корпорации начали видеть ценность не только в бухгалтерских документах, но и в других накапливаемых данных, они начали считать, во сколько им обойдется потеря этих данных. И очень быстро пришли к понимаю, что дешевле инвестировать в надежное хранение данных, чем терять данные и собирать их заново.
Используемый изначально подход хранить данные разрозненными кусками на разных устройствах быстро показал свою неэффективность. Предположим, что корпорации требуется электронная почта, бухгалтерская база и свой веб-сайт. Под каждую из перечисленных задач приобреталось свое устройство, которое и задачу выполняло, и данные хранило на своих накопителях. Но если устройство ломалось, то мы не только получали сломанную почту, но и все данные на нем терялись или были недоступны.
Так родилась концепция современных систем хранения данных: специализированное устройство, надежно хранящее ваши данные. При этом данные на нем может хранить множество сервисов одновременно. Для иллюстрации можно опять вернуться к кулинарной аналогии. Изначально под каждую задачу строилась отдельная кухня (компьютер или сервер) со своей кладовкой (локальными накопителями для хранения данных). А сейчас же принято использовать СХД – централизованный склад для хранения продуктов. Склад (СХД) более вместительный и надежный, чем любая отдельно взятая кухня (сервер или компьютер). Но сам по себе склад еду не готовит (не обрабатывает данные), он просто хранит и отдает их на кухню для последующей обработки (хранит данные и предоставляет их по запросу).
Самым простым способом повысить надежность устройства является дублирование всех его компонентов, а так как никаких сложных вычислений от такого решения не требуется, то и компоненты эти могут быть самыми простыми. Это позволяет нам избежать единой точки отказа – какой бы компонент не вышел из строя, данные останутся доступными и неповрежденными. Сейчас большинство систем хранения данных имеют двухузловую архитектуру, то есть все компоненты, кроме накопителей, в них дублированы. А самые сложные и дорогие СХД могут наращивать количество своих узлов до 8 или даже 16 штук, пропорционально увеличивая количество компонентов.
Обеспечив надежность хранения, необходимо так же не забывать и о других потребностях бизнеса. Так как хранить нам надо данные большого количества сервисов, то и объем этих данных как правило очень велик. А чем больше объем данных, тем больше нам нужно времени, чтобы их считать. Если вам надо заполнить продуктами один холодильник, то у вас уйдет на это меньше часа. А если стоит задача забить едой целый склад – тут может и недели не хватить. Поэтому в архитектуре любой системы хранения больший упор делается именно на накопителях и технологиях по взаимодействию с ними, чтобы обеспечить как большие объемы для хранения данных, так и высокую скорость их работы.
Возможности СХД для защиты данных
Основными характеристиками любой системы хранения данных являются ее объем, надежность хранения данных и скорость доступа к ним. И современные СХД обзавелись набором технологий, позволяющих улучшить эти показатели. Для начала остановимся на надежности данных и их защите.
Не важно, как много данных мы можем записать или как быстро мы можем это сделать, если при этом они окажутся недоступны, повреждены или безвозвратно утеряны. Поэтому надежность хранения является ключевым требованием со стороны бизнеса. Для обеспечения этого требования было разработано множество различных технологий, начиная классическими резервными копиями, и заканчивая сложными метрокластерами с автоматической системой управления. Давайте разбираться как все это работает.
Некоторые технологии позволяют сохранить ваши данные от несанкционированного изменения (“Ой, я ничего не нажимал, оно само все удалилось!”) или частичного повреждения данных (“А что это за странное окошко с надписью СОХРАНЕНИЕ, наверное стоит выключить программу…”). Другие позволяют восстановить поврежденные или потерянные данные, если наша СХД по какой-то причине не справилась с этой задачей (“А давайте выключим этот шкаф, что-то он слишком сильно шумит!”). Ну а катастрофоустойчивые решения позволяют в буквальном смысле защититься от падения метеорита или нападения Годзиллы.
Начнем знакомство с локальных возможностей по защите данных.
RAID
Первое, от чего нам стоит защитить наши данные – поломка накопителя. Для этого много десятилетий назад была предложена технология RAID, объединяющая физические накопители в логическую сущность для повышения их производительности и защиты хранимых на них данных.
Рассмотрим простой пример: нам надо записать на накопители данные A1A2A3. Без использования RAID эти данные будут записаны на первый диск, а второй диск останется пустым. Если при этом первый диск выйдет из строя, то мы потеряем все данные безвозвратно.
Но мы можем объединить два этих диска в RAID1, и тогда каждый блок данных будет одновременно записываться на оба диска. В этом случае при потере любого накопителя полная копия всех данных сохранится на оставшемся накопителе. Есть и обратная сторона медали – каждый блок данных записывается дважды, что приводит к уменьшению итоговой емкости СХД. То есть если взять два диска по 100 Гб и объединить их в RAID1, то мы сможем на такой рейд записать не 200 Гб (2 х 100 Гб), а только 100 Гб, так как каждый блок дублируется.
Существует большое количество уровней RAID, каждый из которых имеет свои сильные и слабые стороны. К примеру: RAID5 позволяет объединять от 3 накопителей, предлагает большую скорость записи, но позволяет без ущерба потерять только 1 накопитель. RAID6 позволяет объединить от 5 накопителей, обладает меньшей скоростью в сравнении с RAID5, но защищает данные от потери 2 накопителей сразу.
Основным преимуществом любых RAID-ов является защита от потери накопителя и увеличение скорости обращения к данным. А недостатком является то, что мы не защищаем данные от аппаратных ошибок: изменение, удаление и повреждение данных не может быть предотвращено силами RAID-а.
Snapshot
Использование RAID защищает от потери данных из-за поломки диска, но не защитит от несанкционированного изменения. Компания может подвергнуться атаке вируса шифровальщика, программа при записи может выдать ошибку и сама испортить все данные. Да и никто не отменяет человеческий фактор и невнимательность при работе с документами. В этом случае нас спасут снапшоты или мгновенные снимки. Суть технологии проста: вы берете данные, которые хотите защитить, создаете их мгновенный снимок во времени и храните его на той же СХД “до востребования”. Если возникает необходимость отменить какие-то изменения данных, то вы просто восстанавливаете их прошлую версию из хранимого снимка.
Основное преимущество технологии – снимки создаются мгновенно и процесс этот может быть автоматизирован. К примеру, вы можете создавать снимок важного документа каждый час. Тогда у вас появляется возможность гибко выбирать, какой именно снимок документа является наиболее актуальным, и восстанавливаться именно на него. А недостатком является то, что при полной потере данных (когда недоступны и текущие данные, и их снимок) мы не можем ничего восстановить.
Миграция между узлами
Как мы уже знаем, архитектура любой современной СХД состоит из 2-х идентичных узлов. Каждый из этих узлов может отвечать за обработку конкретного набора данных. И если один узел выйдет из строя, а диски останутся целыми, то обрабатывать данные начнет другой узел. Но переключение происходит не мгновенно и сопровождается копированием служебной информации. Именно этот процесс и называется миграцией – переход процессов обработки и управления от одного узла СХД к другому.
Резервные копии (бэкапы)
Одна из самых старых и самых надежных технологий для защиты данных – создание резервных копий. При этом мы буквально копируем весь объем защищаемых данных на какой-то внешний для нашей СХД носитель. Ключевым здесь является слово “внешний” – мы выносим резервную копию за пределы нашей СХД, что позволяет нам восстановить наши данные в случае выхода из строя всей системы. При этом восстановление происходит путем обратного копирования. И важно понимать, что чем бОльший объем данных мы хотим защитить, тем дольше мы будем их копировать. Как в момент создания резервной копии, так и в момент восстановления данных из нее.
Еще одной важной особенностью бэкапов является их периодичность. Резервные копии создаются автоматически с заданной периодичность, например, каждую субботу. То есть если по какой-то причине данные будут потеряны в среду, то при восстановлении из последней резервной копии мы потеряем все данные, которые были записаны в период со среды по субботу.
Подытожим: основным преимуществом резервных копий является возможность восстановления данных даже в случае выхода из строя всей СХД. Недостатками же этой технологии является долгое время восстановления данных и риск потери данных, не попавших в резервную копию.
Репликация
Чтобы победить недостатки резервного копирования, была разработана технология репликации. Чтобы ускорить восстановление данных, решили копировать их не просто на внешний носитель, а на другую СХД. Тогда при потере первой СХД нам не надо будет обратно копировать данные для их восстановления, ведь они уже расположены на полностью рабочей СХД. Остается проблема потери данных между процессами копирования. По мере развития технологии репликации стали выделять два независимых типа реализации: синхронная и асинхронная.
Каждый раз, когда кто-то пытается записать данные на СХД, после отправки каждой команды он ждет подтверждения от СХД о том, что данные успешно записаны. И именно последовательность записи и отправки подтверждений является ключевой разницей между двумя типами репликации.
При синхронной репликации первая СХД не отчитается об успешной записи данных, пока не скопирует их на резервную. Это гарантирует нам, что данные на обеих СХД всегда синхронны, и в какой момент бы ни случилась потеря первой СХД – данные сохранятся на резервной без потерь.
При асинхронной репликации первая СХД сразу отчитывается об успешной записи, накапливая внутри себя все изменения. И копирует их на резервную по заданному графику, по сути повторяя подход резервных копий. В этом случае потеря первой СХД приведет к потере данных, скопившихся на ней, но не скопированных на резервную СХД.
И самый главный нюанс любой репликации: фактически хранит данные и предоставляет к ним доступ только первая СХД, поэтому она называется основной. А вторая СХД простаивает, не выполняя никакой полезной работы, поэтому ее называют резервной.
Учитывая все это, главным преимуществом репликации является скорость восстановления данных, на порядок превышающая резервные копии. Недостатком же является высокая стоимость такого решения, так как приходится приобретать резервную СХД, которая фактически не будет использоваться до наступления аварийного инцидента. Также при использовании асинхронной репликации по-прежнему сохраняется риск потери данных, не скопированных на резервную СХД.
Метрокластер
Венцом всех современных технологий по защите корпоративных данных является реализация метрокластера. Отчасти она похожа на репликацию, но есть кардинальные различия. Мы приобретаем не только вторую СХД, но и дублируем целиком всю нашу ИТ-инфраструктуру (приложения, сервера, сетевое оборудование и СХД), размещая их в двух разных дата-центрах (площадках). В этом случае, у нас уже нет активного и резервного участников, оба набора оборудования активно используются для решения бизнес-задач, равномерно распределяя нагрузку друг между другом.
В этом случае, любая неисправность СХД на одной из площадок никак не отразится ни на самих сервисах, ни на их данных. Сами приложения и сервисы продолжат работу на второй площадке, а данные будут доступны с любой из оставшихся СХД. А для самых критических инфраструктур, где недопустимы даже секундные задержки или потеря минимального количества данных, возможно комбинирование всех технологий защиты сразу.
Создаются площадки с идентичным набором оборудования. Каждая СХД защищает свои данные с использованием технологии мгновенных снимков и резервных копий. И одна из площадок дополнительно реплицирует свои данные на третью, резервную площадку. В этом случае исключаются любые возможности потерять корпоративные данные даже в случае катастроф и других форс-мажорных факторов.
Возможности СХД для повышения емкости и производительности
Дедупликация и компрессия
Обеспечив надежное хранение и защиту данных, производители СХД начали искать способы улучшить другие характеристики своего продукта. И так как объем ценных для бизнеса данных растет с устрашающей скоростью, то и стоимость их хранения становится все более острой проблемой.
В ответ на это начали развиваться технологии по уменьшению объема хранимых данных – дедупликация и компрессия. Очень похожие на первый взгляд, и такие разные по сути методы снижения объема данных.
Представим, что у нас есть гигантский шкаф. Внутри он разбит на множество полок одинакового размера и заполнен одеждой. Вы понимаете, что место в шкафу закончилось, и новую одежду некуда положить.
Если вы начнете перекладывать одежду внутри полок, пытаясь сложить ее более компактно и заполнить больше пустот – это компрессия или сжатие.Если вы начнете перебирать одежду, находить одинаковые вещи и выкидывать их, оставляя только по одной штуке каждого – это дедупликация. Конечно, с данными все чуть сложнее, но такая аналогия нагляднее всего демонстрирует разницу.
Технология сжатия анализирует содержание каждого блока с данными, выискивая ненужную служебную информацию, от которой можно избавиться. Важно, что у процедуры компрессии есть обратный процесс – декомпрессия. В результате него объем данных должен восстановиться до исходного без потери содержания.
В свою очередь дедупликация не столько смотрит содержание блоков с данными, сколько сравнивает их друг с другом. И если система понимает, что точно такой же блок уже был записан на накопители, то она не будет записывать дубликат, а просто укажет ссылку на существующий.
Разные по структуре данные могут лучше сжиматься или дедуплицироваться, а некоторые данные прекрасно делают и то, и другое. В зависимости от типа приложения, которое генерирует данные, мы можем получить экономию дискового пространства от 2-х до 10-ти раз. То есть чтобы записать 100 Тб данных, нам достаточно приобрести только 10 Тб накопителей, если данные могут сжиматься и дедуплицироваться в 10 раз.
SSD-кэширование
Чем бОльший объем данных мы можем хранить, тем больше времени тратится на его запись или чтение. Поэтому вопрос скорости доступа к данным становится не менее критичным, чем их объем. Одной из технологий, позволяющих ускорить доступ к данным, является кэширование. Суть этой технологии проста: если у нас есть накопители с разной скоростью, то для ускорения записи или чтения данных на медленные накопители мы можем предварительно “положить” эти данные на быстрые накопители, использовав их как промежуточный слой. А так как у нас есть несколько типов накопителей, то мы можем использовать SAS SSD и NVMe SSD для значительного прироста скорости.
При этом кэширование записи и чтения работают по разным принципам. Кэширование записи кладет на промежуточный слой любую команду на запись. После этого СХД сразу отчитывается приложению, что данные успешно записаны, и в фоновом режиме копирует их с быстрых SSD на медленные HDD (или с супер-быстрых NVMe SSD на просто быстрые SAS SSD).
А вот кэширование чтения требует сбора определенной статистики. Если СХД замечает, что один и тот же блок данных требуется считать чаще, чем все остальные, то она сама копирует его в кэш. После этого каждая следующая команда на чтение этого блока будет обработана быстрым кэшем, а не медленными накопителями.
QoS
Последней технологией, косвенно повышающей скорость доступа к данным, можно считать QoS (Quality of Service). По своей сути эта технология позволяет назначать приоритеты приложениям, если они хранят свои данные на одной СХД.
Рассмотрим пример: на одной СХД размещены данные корпоративной почты, бухгалтерской базы данных и сетевая папка для хранения корпоративных документов. Предположим, что в конце года прошел новогодний корпоратив, на сетевую папку выложили фото и видео, и все сотрудники начали их качать и смотреть. При этом загрузив все мощности СХД и забив корпоративную сеть. А бухгалтерии надо закрывать финансовый год, но их база недоступна, так как СХД перегружена из-за фото и видео.
Для предотвращения такой ситуации администратор СХД может назначить приоритет для приложений, настроив правила таким образом, что если для критичных сервисов (бухгалтерской базы данных) не хватает мощностей, то они будут принудительно забираться у менее критичных сервисов (сетевой папки). То есть скорость на чтение и запись некритичных сервисов будет ограничиваться, чтобы гарантировать скорость доступа к критичным ресурсам.
Отслеживать