технический директор Stack Group
В настоящее время мы наблюдаем тренд переноса информационных систем наших заказчиков на SSD (Solid State Drive). Довольно продолжительное время названный тип накопителей был недоступен для повсеместного использования ввиду дороговизны. Покупка All-Flash-массивов, построенных полностью на SSD-носителях, тогда была оправдана только для бизнес-критичных приложений, которые предъявляют самые высокие требования к быстродействию (Input/Output Operations per Second, IOPS – количеству операций ввода-вывода и минимальному времени отклика) системы хранения. За прошлый год стоимость Flash-носителей заметно снизилась, а все опасения, связанные, как считалось, в первую очередь с ограниченным количеством циклов перезаписи, окончательно развеялись.
Предпосылки перехода на All-Flash-массивы
Сегодня все больше производителей систем хранения данных стали предлагать доступные (стоимость хранения 1 ГБ на SSD стала сопоставима со стоимостью хранения 1 ГБ на 15K SAS) и достаточно производительные All-Flash-массивы. Одновременно с этим производители Flash-памяти выпускают на рынок диски, емкость которых уже превышает объемы классических магнитных жестких дисков (HDD). Так, компания Samsung еще в середине 2016 г. анонсировала выход 15,36 ТБ SSD [1], а к 2020 г. – 100 ТБ SSD [2]. Кстати, примерно в то же время компания Seagate представила твердотельный диск объемом целых 60 ТБ [3]!
Ряд исследований и статистика, накопленная такими гигантами, как Google [4] и Facebook [5], показали, что SSD-диски достаточно надежны при длительном использовании и их можно и нужно без каких-либо опасений использовать как для хранения, так и для обработки информации, чувствительной к времени доступа. В целом их надежность находится на уровне HDD и возраст диска имеет намного большее значение, чем ресурс перезаписи.
Благодаря исследованиям стало очевидно, что существенной разницы в уровне отказоустойчивости как более дорогих SLC (Single-Level Cell), так и более доступных MLC (Multi-Level Cell) и eMLC (enterprise Multi-Level Cell) дисков нет. Наличие сбойных блоков является нормой, к тому же в процессе эксплуатации их число может увеличиваться, однако наличие большого их количества изначально – повод насторожиться, ибо вероятность выхода такого диска из строя достаточно велика [6].
Сложности замены HDD на SDD
Простой замены классических SAS (10K, 15K) или NL-SAS (7.2K) дисков на SSD было бы явно недостаточно: от производителей систем хранения данных потребовалось нечто большее. Производители, которые просто заменяли HDD на SSD, столкнулись с рядом новых проблем. Одним из узких мест системы хранения данных стали контроллеры и пропускная способность backbone-интерфейсов. Количество ядер на микропроцессорах контроллеров частично решали эту проблему, однако ненадолго, а применение технологий дедупликации (когда одинаковые блоки данных физически не занимают дополнительного места на массиве, существует только указатель на них) и компрессии и вовсе свело на нет все усилия по простой замене CPU прошлых поколений более многоядерными и производительными. Даже самые производительные х86 процессоры, на которых построены современные контроллеры СХД, сейчас не справляются с огромным количеством дисковых операций ввода-вывода.
Производители современных массивов часто заявляют производительность свыше 1M IOPS. Здесь, конечно же, важно понимать, о каком характере нагрузки идет речь, поскольку очевидно, что нельзя ориентироваться только на значение IOPS без учета характера нагрузки и Latency. Наилучшего показателя можно ожидать на операциях чтения. Самое очевидное решение проблемы с производительностью CPU – увеличение количества контролеров в массиве (более двух), но такой подход является эффективным, если контроллеры работают в Active-Active-режиме и умеют работать со всеми дисками массива. В противном случае увеличение количества контроллеров практически ничем не отличается от простой установки рядом нового массива и логической связки этих массивов. Информация в режиме работы контроллеров массива Active-Active может размещаться небольшими блоками (например, 1 ГБ) по всем дискам массива, тем самым обеспечивая равномерное распределение информации и одинаковой нагрузки на всех дисках массива. При подобном сценарии распределения информации становится очевидным, что, несмотря на использование все тех же старых и проверенных методов обеспечения отказоустойчивости, как RAID, мы уходим от многих проблем, таких как существенное время ребилда (перестроение RAID в случае выхода из строя одного или более физических дисков, может занимать до нескольких часов) и просадка производительности массива в момент ребилда.
Также стоит отметить, что ранее при выделении отдельных дисков под горячую замену (hot spare) некоторые производители даже применяли специальные алгоритмы, проверяющие работоспособность этих дисков и их готовность встать в строй вместо неисправного. Из опыта Stack Group можно сказать, что мы несколько раз были свидетелями того, как spare-диски выходили из строя, фактически находясь в состоянии покоя (не под нагрузкой). При распределении блоков с данными по всем дискам массива нет необходимости выделять отдельные диски как spare. В этом случае роль spare выполняет свободное (зарезервированное под spare) пространство диска ровно в том объеме, который требуется для вашей конфигурации и обеспечения требуемого уровня отказоустойчивости. При таком подходе износ дисков происходит более равномерно.
Интересным выглядит и решение с применением специализированных чипов, которые снимают большую часть нагрузки с CPU и выполняют специфические функции, такие как детектирование нулей, аппаратная поддержка XOR (для подсчета контрольных сумм в RAID5, RAID6), дедупликация и т. д. Подобный подход позволяет системе существенно освободить ресурсы CPU контроллера, особенно если речь идет о All-Flash массивах.
Еще одна проблема, с которой сталкиваются производители массивов, – недостаточная пропускная способность интерфейсов, связывающих контроллеры и дисковые полки (например, SAS 3). Да и в целом пропускная способность SAN (Storage Area Network) ставится под сомнение при повсеместном внедрении Flash. Итак, представим, что мы получаем 300K IOPS на чтение 4K-блоками в несколько потоков с одного обычного SSD-диска. Соответственно такой диск способен (300 000 × 4096 = 9,8 Гбит/с) практически полностью утилизировать канал SAS 3 (12 Гбит/с). Становится очевидным, почему некоторые производители устанавливают не полностью укомплектованные дисковые полки в свои массивы. Если же говорить о NVMe, то тут уже точно не хватит текущей пропускной способности SAN.
Преимущества и недостатки программно-определяемых СХД
Следует упомянуть о таком направлении, как SDS (Software-Defined Storage), когда хранение и обработка данных осуществляются на одном и том же сервере. При таком подходе одновременно решается целый ряд проблем, но появляются и новые. Очевидный плюс решения: мы получаем столько контроллеров СХД, из скольких узлов состоит кластер SDS. Путь к данным максимально короток, поскольку используется локальная шина передачи данных. Однако здесь стоит оговориться, что для обеспечения отказоустойчивости используется в самом простом случае зеркалирование данных на другие узлы кластера (похоже на технологию RAID-1). В идеале же данные не могут считаться записанными, пока не придет ответ (по сети) от удаленного узла, что данные записаны. Для минимизации задержек, вызванных этим фактом, рекомендуется применять при построении сети передачи данных низколатентные коммутаторы (например, Arista DCS-7150S, Juniper QFX).
Какие же проблемы нас могут ожидать здесь? Первая – когда одновременно на одном узле возникает ситуация, при которой одна виртуальная машина (VM) активно использует CPU, а другая пытается интенсивно работать с вводом-выводом данных. В подобном сценарии CPU узлы оказываются перегруженрыми, и единственный выход – миграция VM на другой узел, что, в свою очередь, не лучшим образом отразится на производительности VM в процессе миграции.
Вторая проблема – сложности, которые могут возникнуть при начальном сайзинге и дальнейшем масштабировании. Далеко не всегда, особенно в условиях работы сервис-провайдера, удается предсказать пропорцию потребления CPU и RAM относительно дискового пространства. Зато применение SDS значительно упрощает архитектуру решения, требует наличия меньшего числа разнопрофильных специалистов и позволяет вводить новые мощности в производственную эксплуатацию максимально быстро, в идеале просто подключая новый сервер к питанию и сети передачи данных.
Основные преимущества All-Flash
Перечислим теперь основные преимущества, которые мы получаем при миграции информационных систем на All-Flash-массив. Во-первых, как было упомянуто выше, это быстродействие и низкое время отклика (время произвольного доступа в несколько раз меньше, чем у магнитного жесткого диска). Это особенно важно в средах, где применяется виртуализация, так как со стороны серверной инфраструктуры, где развернут тот или иной гипервизор, нагрузка на СХД практически всегда носит произвольный характер.
Во-вторых, для заказчиков, которым нужна гарантированная производительность, во многих All-Flash-массивах реализованы функциональные возможности QoS (Quality of Service), что позволяет установить конкретное количество операций ввода-вывода (IOPS) и время отклика (Latency), которые будут гарантированно предоставляться массивом для конкретного тома с данными.
Стоит отметить, что технологии онлайн-дедупликации и компрессии, а также выделение места по принципу thin provisioning (метод выделения пространства хранения не сразу, а по мере возникновения в нем потребности) позволяют в ряде случаев достигать стоимости хранения, сопоставимой со стоимостью хранения на дисках SAS (10K), а иногда даже NL-SAS (7,2K).
Области эффективного использования гибридных массивов
Безусловно, не стоит переносить на All-Flash-массивы все задачи без исключения. Необходимо провести анализ информационных систем, которые являются наиболее нагруженными, и после этого принимать решение о необходимости покупки или запроса у сервис-провайдера более производительной системы хранения. Для целого ряда задач, например VDI (Virtual Desktop Infrastructure), хорошо зарекомендовали себя решения с применением специальных Flash-карт (ускорителей) или SSD-дисков как в качестве кэша, так и в качестве дополнительного уровня тиринга. То есть получается, что дисковый массив представляет собой слоеный пирог из дисков SSD, FC (Fast Class) и NL-SAS. Наименьший процент в объеме занимают твердотельные накопители, но они используются только для «горячих» блоков данных и в зависимости от производителя и способа применения могут хранить такие блоки как временно (кэш), так и условно постоянно (до тех пор, пока эти блоки являются «горячими») – тиринг. Для VDI-решений зачастую этого более чем достаточно, чтобы избежать таких неприятных явлений, как boot storm, когда в начале рабочего дня происходит одновременная загрузка сотен и даже тысяч виртуальных рабочих мест и система хранения, а точнее диски, на которых расположены данные этих VDI, становится тогда одним из узких и наименее производительных мест.
Некоторые производители систем хранения применяют «умные» алгоритмы кэширования, позволяющие экономить место в кэш-памяти и размещать там только уникальные блоки данных. Поэтому дедуплицированные блоки не дублируются в кэш-памяти, тем самым предоставляя существенную экономию кэша. В совокупности с применением технологии дедупликации и компрессии вы получаете одновременно и колоссальную экономию дискового пространства. Такие способы весьма эффективны и при работе с базами данных, но здесь нужно быть крайне осторожными и, если имеется такая возможность, предварительно протестировать работу базы данных на массиве с применением технологии тиринга. Безусловно, идеальным решением будет выделение индивидуальной политики перемещения «горячих» и «холодных» блоков данных для конкретной базы данных.
На текущий момент современные All-Flash-массивы предлагают превосходную производительность для бизнес-критичных приложений, а технологии компрессии и дедупликации позволяют получать намного больше полезной емкости на массиве, причем практически без потерь производительности. Возросшая популярность All-Flash-массивов и ускоренная миграция информационных систем на них обусловлены предъявлением новых требований со стороны конечных заказчиков, которые в полной мере планируют использовать бизнес-критичные приложения с высокими требованиями к дисковой подсистеме и/или внедряют виртуализацию в свои инфраструктуры.
Безусловно, миграцию на Flash-системы стоит рассматривать в первую очередь сервис-провайдерам, которые предоставляют свою инфраструктуру как сервис (IaaS) на базе технологий виртуализации, а также тем, кто планирует отказаться от старых массивов, производительность в которых достигалась большим количеством дисков (шпинделей) SAS 15K небольшого объема.
Мы внимательно следим за развитием направления SDS, так как считаем его очень перспективным и, при достаточной зрелости, способным стать следующим эволюционным шагом в подходе к хранению и обработке данных. На наш взгляд, при выборе системы или подхода к хранению данных, будь то покупка или аренда дисковых ресурсов, важно учитывать не только стоимость, но и технологичность, а также уровень технической поддержки вендора используемой системы хранения данных.
Источники
- https://news.samsung.com/global/samsung-now-introducing-worlds-largest-capacity-15-36tb-ssd-for-enterprise-storage-systems
- http://www.eteknix.com/samsung-reveals-32tb-2-5-inch-ssd-100tb-by-2020/
- http://www.seagate.com/ru/ru/about-seagate/news/seagate-accelerates-enterprise-momentum-with-two-new-flash-products-pr/
- http://research.google.com/archive/disk_failures.pdf
- http://users.ece.cmu.edu/~omutlu/pub/flash-memory-failures-in-the-field-at-facebook_sigmetrics15.pdf
- https://www.usenix.org/sites/default/files/fast16_full_proceedings.pdf
