Многоуровневое хранение данных и избыточное выделение ресурсов
Что такое избыточное обеспечение?
Как я указывал в предыдущей статье этой серии, еще одной распространенной проблемой, связанной с технологиями хранения данных с прямым подключением (DAS), помимо расширения хранилища, является проблема избыточного выделения ресурсов. Что такое избыточное обеспечение? Это в основном, когда вы покупаете больше, чем вам нужно чего-то.
Излишнее выделение ресурсов хранилища распространено в мире ИТ по ряду причин. Например, ИТ-отделы в компаниях, которые медленно растут с течением времени, часто используют органический подход к построению ИТ-инфраструктуры. Например, предположим, что компания расширила свой отдел продаж в связи с вашей новой маркетинговой кампанией, и вам нужен еще один сервер, чтобы справиться с нагрузкой на вашу систему управления контентом. Что вы делаете? Вы покупаете другой сервер с достаточным количеством DAS для обработки дополнительной нагрузки, и на всякий случай убедитесь, что в DAS более чем достаточно дисков для удовлетворения потребностей вашего растущего отдела продаж.
Или, скажем, медиа-отделу вашей компании поручен новый проект, включающий создание большого количества видеофайлов. Что вы делаете? Вы покупаете сетевое хранилище (NAS) для отдела, чтобы они могли хранить эти файлы. И опять же, просто на всякий случай убедитесь, что NAS предоставляет более чем достаточно места для хранения, чтобы удовлетворить потребности отдела.
Вы, вероятно, видите, к чему это ведет — это снова проблема разрастания хранилища. См. мою предыдущую статью из этой серии, чтобы узнать, почему разрастание — это плохо, когда речь идет о хранении бизнес-данных. Но в этих примерах есть еще один элемент, а именно «на всякий случай». Что это означает?
Во-первых, это подразумевает некомпетентность или, по крайней мере, лень со стороны ИТ-отдела. В частности, они не предприняли никаких усилий, чтобы составить надежный прогноз того, как могут вырасти потребности в хранении для отдела продаж или медиа-отдела в течение срока действия кампании или проекта. Конечно, проекты могут быть ненадежными, но когда речь идет о деньгах, результат перерасхода в одной области может означать, что вам не хватит на другие нужды. Поэтому важно, чтобы ИТ-специалисты выработали дисциплину составления надежных и обоснованных прогнозов, когда им необходимо закупить и предоставить хранилище и другие ресурсы.
Однако второй и более важной может быть глубинная мотивация, которая побуждает ИТ-отдел принимать решения «просто на всякий случай», такие как избыточное выделение ресурсов. Эта мотивация — просто страх.
На заре вычислительной техники обработка и хранение данных были дорогими и использовались в основном военными и академическими кругами. По мере того, как компьютеры проникали в деловой мир, первыми их начали применять представители банковской и финансовой индустрии. Если и есть что-то, чего банки боятся больше всего, так это потери денег. В результате укоренилась идея о том, что основная задача ИТ-отдела состоит в обеспечении того, чтобы каждый бит данных всегда был надежным и точным. В конце концов, есть большая разница между 1 000 000 000 долларов на балансе и 0 000 000 000 долларов! Если произойдет такая ошибка, в ИТ-отделе банка наверняка покатятся головы, и страх потерять работу является хорошей мотивацией для того, чтобы не рисковать в отношении выделения хранилища в таких ситуациях.
В результате в самой генетике корпоративного ИТ-отдела закрепилась идея о том, что данные ценны и их целостность не должна подвергаться риску ни при каких обстоятельствах. Чтобы это произошло, были изобретены различные алгоритмы обеспечения целостности данных и созданы такие технологии, как зеркалирование RAID и отказоустойчивая кластеризация. Конечно, хранить эту таблицу на зеркальном диске стоит дороже, но что с того? Весь ад может разразиться, если электронная таблица будет повреждена или потеряна. Поэтому «на всякий случай» давайте сохраним его на томе RAID 0 в кластере из двух узлов, который в реальном времени реплицируется на второй кластер, расположенный на другом сайте…
К сожалению, как только вы пристрастились к мышлению «стоимость не имеет значения», основанному на страхе перед последствиями потери данных, изменить его будет очень сложно. И это основная причина, по которой, несмотря на все разговоры об управлении рисками и компромиссах, о хранении как о товаре и т. д., ИТ-отделы по-прежнему имеют сильную тенденцию к избыточному выделению ресурсов хранения и тем самым трате денег своей компании.
По той же причине я брал с собой в экзаменационную комнату два калькулятора во время учебы в университете по физике — я хотел иметь запасные на случай, если один из них выйдет из строя. Говоря о калькуляторах, я был одним из первых пользователей калькулятора HP-35, и для тех из вас, кто достаточно взрослый и ностальгирует, чтобы заботиться, есть потрясающий сайт, который вы должны посетить: Музей калькуляторов HP по адресу http://hpmuseum..орг.
Избыточное выделение ресурсов и разрастание хранилища
Излишнее выделение корпоративного хранилища тесно связано с разрастанием хранилища для серверов. Причина этого в том, что массивы DAS реализуются отдельно для каждого сервера. Это означает, что каждый массив DAS должен иметь достаточно места для хранения данных, необходимых серверу, к которому он подключен. И сколько хранилища DAS достаточно для моего сервера? Обычно ответ заключается в том, что «просто на всякий случай» я выделяю более чем достаточно места для хранения, чем на самом деле нужно моему серверу.
Видите ли, проблема здесь в том, что прогнозирование носит статистический характер, а это означает, что чем больше набор данных, с которым вы работаете, тем точнее вы можете предсказать будущие потребности (при условии, что все остальные условия равны). Другими словами, трудно точно предсказать, насколько увеличится объем хранилища данных на отдельном сервере, на котором выполняется одно бизнес-приложение, с течением времени, если хранилище данных будет использоваться только этим сервером. И еще труднее точно спрогнозировать рост объема хранения данных для многих серверов, каждый из которых имеет собственный выделенный массив DAS. Конечный результат множества небольших прогнозов, подобных этому, вероятно, приведет к тому, что некоторые массивы DAS будут крайне недоиспользованы (около 25 % или меньше), некоторые недоиспользованы (около 50 %), некоторые хорошо использованы (около 75 %), а некоторые почти полностью загружены. насыщенный (>90%). В результате у вас будет много неиспользуемого дискового пространства на недоиспользуемых массивах, а также вы окажетесь на опасной территории с бизнес-приложениями, работающими на серверах, чьи массивы почти заполнены:
Рис. 1. Хранилище DAS может привести к нерациональному использованию пространства на серверах, где массивы используются недостаточно, и может поставить под угрозу надежность приложений на серверах, где массивы почти заполнены.
Напротив, если все хранилище данных вашего сервера объединено в единый массив, такой как SAN, вашим хранилищем легче управлять, и вы можете обеспечить его эффективное использование в любое время. Избегается потеря пространства из-за недостаточного использования хранилища (таким образом, экономятся деньги) и предотвращается опасность нестабильности приложений в результате переполнения хранилища (таким образом избегая отчуждения ваших клиентов):
Рис. 2. Хранилище SAN позволяет эффективно управлять хранилищем, обеспечивая постоянное эффективное использование дискового пространства.
А за счет обеспечения более высокого уровня использования хранилища консолидация хранилища также может сэкономить вашей компании значительные средства. Несмотря на то, что первоначальные первоначальные затраты на оборудование массива SAN и коммутационную матрицу выше, поскольку хранилищем SAN можно более эффективно управлять для обеспечения более высоких уровней использования (обычно от 75 до 80 %), чем DAS (обычно в среднем около 50 %, поскольку синдрома «на всякий случай») это означает, что наступает компромисс, когда общий размер хранилища (количество дисков в массивах), после которого хранилище SAN начинает дешеветь в пересчете на байт, чем хранилище DAS:
Рис. 3. В какой-то момент SAN становится более дешевым решением для хранения данных, чем DAS.
Избыточное выделение ресурсов и многоуровневое хранение данных
Однако переноса серверного хранилища с DAS на SAN недостаточно для обеспечения эффективного использования хранилища. Что вам также нужно сделать, так это реализовать стратегию многоуровневого хранения данных.
Многоуровневое хранение данных — это просто практика хранения ваших бизнес-данных на устройствах хранения, подходящих для каждого типа данных. Недавно полученные данные (горячие данные) ценны, потому что, если вы их потеряете, вы можете потерять продажу или оттолкнуть клиента. В результате горячие данные всегда должны храниться в хранилище уровня 1, которое является быстрым, высоконадежным, всегда доступным и удобным для поиска. Это также, как правило, дорого, поскольку для таких целей обычно используются жесткие диски SAS или SCSI емкостью 15 КБ (HDD) или даже твердотельные накопители (SSD), поэтому вы хотите минимизировать объем данных, хранящихся в хранилище уровня 1.
Напротив, более старые данные (устаревшие или неактуальные данные) менее ценны и поэтому могут быть перемещены в хранилище уровня 2, которое работает медленнее, имеет приемлемую надежность, не зеркалируется и не реплицируется, а поиск в нем может быть медленнее, поскольку он не требуется часто.. Хранилище уровня 2 обычно состоит из недорогих стандартных жестких дисков большой емкости в массиве SAN или NAS.
Обычно также требуется архивировать данные, которые больше не нужны для повседневных бизнес-операций. Такие холодные данные обычно перемещаются из хранилища уровня 2 в хранилище на магнитной ленте (уровень 3) и хранятся только для целей архивирования и соблюдения нормативных требований.
Рис. 4. Характеристики хранилища, используемого для многоуровневого хранения данных.
Вывод
Избыточного выделения ресурсов можно избежать за счет сочетания консолидации хранилища и многоуровневого хранения данных. В следующей статье мы рассмотрим некоторые стратегии реализации многоуровневого хранения данных.