Стратегии многоуровневого хранения данных

Быстрый обзор

Давайте начнем с краткого обзора того, что мы уже узнали в этой серии:

• Разрастание хранилища происходит, когда каждый сервер в вашей организации имеет собственное хранилище с прямым подключением (DAS). Решением проблемы разрастания хранилища является консолидация хранилища. Это лучше всего достигается путем переноса данных сервера из DAS в SAN.
• Избыточное выделение хранилища — это когда вы покупаете больше необходимого вам оборудования для хранения. Это часто происходит в средах, где DAS используется для серверного хранилища, и результатом может быть как недоиспользование (неиспользуемое место для хранения), так и нестабильность приложений из-за переполнения устройств хранения. Решение проблемы избыточного выделения ресурсов хранения — это сочетание консолидации хранилищ и многоуровневого хранения данных.
• Многоуровневое хранение данных — это практика хранения бизнес-данных на устройствах хранения, подходящих для каждого типа данных. Это означает хранение горячих данных в хранилище уровня 1, которое является быстрым, высоконадежным, всегда доступным и удобным для поиска; крутые данные в хранилище Tier 2, которые медленнее, имеют приемлемую надежность, не зеркалируются и не реплицируются, медленнее для поиска; и холодные данные о хранилище уровня 3 для архивных и нормативных целей. Уровень 1 обычно использует корпоративные жесткие диски, которые могут быть жесткими дисками или твердотельными накопителями. Уровень 2 обычно использует недорогие стандартные жесткие диски большой емкости. А уровень 3 обычно использует ленту.

Преимущества многоуровневого хранения данных

Многоуровневое распределение данных может предоставить вашей компании ряд различных преимуществ. Самым большим из них, очевидно, является то, что вы можете сэкономить деньги. Например, допустим, вы определили, что ваши бизнес-данные составляют 20 ТБ и разбиты следующим образом:

• 10 % ваших бизнес-данных — это горячие данные (ценные данные, которые были недавно получены и могут в любой момент понадобиться вашим бизнес-приложениям).
• 50% ваших бизнес-данных — это классные данные (устаревшие данные, которые менее ценны и могут понадобиться бизнес-приложениям лишь изредка).
• 40% ваших бизнес-данных — это холодные данные, которые больше не нужны, но должны храниться в архивной форме на случай, если регулирующие органы когда-либо потребуют их.

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

Рис. 1. Наши затраты составляют 40 000 долларов США, если мы используем только один уровень для хранения данных.

Теперь давайте посмотрим, сможем ли мы сэкономить деньги, внедрив многоуровневое хранение данных, как описано выше:

Рис. 2. Внедрение многоуровневого хранения данных сокращает расходы на хранение вдвое!

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

К другим преимуществам многоуровневого хранения относятся:

• Улучшена производительность критически важных бизнес-приложений уровня 1. Значительно сократив объем данных, хранящихся в хранилище уровня 1, вы можете повысить скорость отклика приложений, работающих с такими данными. Кроме того, деньги, которые вы сэкономите за счет многоуровневого хранения данных, могут позволить вам приобрести более быстрые жесткие диски корпоративного класса для хранения уровня 1 и реализовать другие стратегии, такие как репликация данных, чтобы обеспечить бесперебойную работу ваших приложений уровня 1.
• Улучшите производительность резервного копирования в целом. Перенося большую часть данных в хранилище уровня 2, вы можете ускорить процесс резервного копирования для хранилища уровня 1 и реже выполнять резервное копирование для хранилища уровня 2. Вы также упрощаете восстановление данных из резервной копии.
• Улучшить поиск. Сохраняя только горячие данные на уровне 1, вы можете сделать поиск приложений уровня 1 более эффективным.

Почему не реализовано многоуровневое распределение данных

Если многоуровневость данных так хороша, почему она не применяется чаще в бизнес-средах? Для этого есть несколько причин, некоторые из которых я описал в предыдущей статье этой серии. Причины отказа от реализации многоуровневого хранения данных могут включать:

• лень. Кто-то однажды сказал, что исполнение требует и планирования, и дисциплины. К сожалению, планирование требует усилий, а дисциплина — это, по сути, усилия, которые последовательно прилагаются с течением времени.
• Занятость. Иногда дело не в том, что мы ленивы, как в ИТ-специалистах, а просто в том, что мы слишком заняты, чтобы тщательно планировать и последовательно реализовывать хорошее решение проблемы. Чтобы обойти это препятствие, нужно научиться эффективно расставлять приоритеты в использовании времени, и в этом отношении мне очень помогли четыре квадранта Стивена Кови. Для быстрого и полезного обзора см. эту статью из White Dove Books, но вам следует прочитать книгу Кови, если вы действительно хотите освоить тайм-менеджмент.
• Страх. Я уже говорил о том, как боязнь потери данных затрудняет внесение изменений в инфраструктуру ИТ-среды. Это связано с тем, что изменения всегда влекут за собой некоторую степень риска, и если вы боитесь вносить изменения, потому что боитесь потерять ценные бизнес-данные (и, следовательно, свою работу), вам нужно научиться рационально управлять рисками и справляться с часто конфликтующими ситуациями. требования вышестоящего руководства.
• Политика. Еще одним препятствием для внесения изменений в инфраструктуру может быть политика, особенно на крупных предприятиях, где разные группы владеют вычислительными, сетевыми ресурсами и ресурсами хранения. Вы должны стремиться преодолеть такой разрозненный менталитет, четко демонстрируя потенциальные преимущества, которые могут быть достигнуты за счет внедрения решения для многоуровневого хранения данных.
• Невежество. Никому не нравится признавать, что они неправы или что они чего-то не знают или не знакомы с технологией или практикой. IT-специалисты в этом плане ничем не отличаются от других. Если вы не знаете, как работает SAN или как определить, какие типы данных должны быть выделены для каждого уровня хранения, вам просто нужно начать учиться. И да, обучение требует времени и усилий, так что не ленитесь!

Стратегии реализации многоуровневого хранения данных

На базовом уровне разработка и реализация стратегии многоуровневого хранения данных ничем не отличается от любого другого ИТ-проекта и включает в себя четыре элемента: объем, ресурсы, график и риск:

Рисунок 3: Четыре элемента любого проекта.

Это означает, что вам нужно начать с четкой формулировки ваших целей и бюджета. Вы собираете команду и распределяете обязанности. Команда разрабатывает необходимые шаги, определяет любые риски, связанные с каждым шагом, и разрабатывает стратегии для снижения этих рисков. После завершения плана проекта вы выполняете тесты в безопасной среде. Если тесты пройдены, вы затем пилотируете проект, используя приложения и данные с низким уровнем риска. Если пилотный проект прошел успешно, вы начинаете внедрять изменения упорядоченным образом, оценивая каждый этап реализации. Наконец, вы закончили, но не совсем так, как вам нужно, чтобы убедиться, что все правильно задокументировано и имеется соответствующая поддержка на случай, если что-то пойдет не так в будущем.

После всего этого вы надеетесь, что ваш успех будет признан и вознагражден руководством, но обычная награда — это просто дополнительная работа и назначение других проектов! Ну, это вам ОНО…

В любом случае, некоторые стратегии и советы, относящиеся конкретно к проектам многоуровневого хранения данных, включают следующее:

• Определите различные типы данных, обрабатываемых бизнес-приложениями в вашей среде. Примеры могут включать документы, презентации, мультимедиа, электронную почту, данные о клиентах, данные о продуктах, финансовые данные и т. д. Некоторые из них будут в виде файлов (.docx,.xlsx,.pptx и т. д.), а другие — в формате структурированной базы данных.
• Определите, к какому уровню хранения лучше всего относится каждый тип данных. Уровень для данных определенного типа также может зависеть от таких факторов, как время создания данных или последний доступ к ним, кто создал данные и другие соображения. Например, файлы.pptx для презентации, которая будет представлена на собрании компании на следующей неделе, могут считаться горячими данными, в то время как файлы.pptx, созданные более 6 месяцев назад, могут считаться важными данными, а файлы, созданные более двух лет назад, могут считаться важными данными. считаются холодными данными.
• Решите, будете ли вы внедрять многоуровневое хранение вручную или использовать какую-либо форму автоматизации для перемещения устаревших данных с уровня 1 на уровень 2 и с уровня 2 на уровень 3. Если вы планируете консолидировать существующее хранилище DAS в SAN, вам следует убедиться, что SAN вы думаете о приобретении включает в себя некоторую форму функциональности динамического многоуровневого хранения данных. В противном случае вам может понадобиться собрать собственное решение для автоматического распределения по уровням с помощью сценариев.
• Разверните и настройте устройства хранения уровня 1, 2 и 3. Для сред SAN у вас могут быть оба уровня 1 и 2 в одной и той же SAN, но с использованием разных типов дисков для номеров логических устройств (LUN), используемых для каждого уровня хранения. Или вы можете решить хранить горячие данные на аппаратных RAID-массивах на каждом сервере и создать сценарии для переноса данных из этих массивов в хранилище уровня 2 в вашей SAN по мере устаревания и устаревания данных.
• Начните с переноса холодных данных в хранилище уровня 3 (обычно на ленту). Как только это будет сделано, вы можете перенести свои «хорошие» данные в хранилище уровня 2 и либо оставить свои «горячие» данные в существующем хранилище сервера, либо перенести их в новое хранилище уровня 1.

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

Вывод

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