Некоторое время назад я с удовольствием прочитал статью Робина Харриса «Почему SSD устарели». Он сделал несколько справедливых замечаний, поскольку преимущественно используемые в системах хранения интерфейсы (SAS и SATA) отчаянно нуждаются в переработке.

В конце концов, нынешнее поколение интерфейсов SAS и SATA представляет собой просто эволюционное усовершенствование технологий SCSI и ATA, появившихся несколько десятилетий назад. С тех пор серверные технологии и потребности приложений с интенсивным использованием данных переросли возможности этих интерфейсов.

Должна ли отрасль, как полагает Робин, подумать о модернизации нашей фундаментальной технологии передачи данных и организации межсоединений в системах хранения? Да, черт возьми.

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

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

Расставим все по своим местам. Оборудование для построения корпоративных SAN и NAS относится к категории сверхдорогого. На него приходится по меньшей мере треть, если не более, расходов на все аппаратное оснащение ЦОДа. И хотя у производителей таких продуктов прочная репутация, а вы используете эти устройства, чтобы хранить наиболее важные данные, давайте посмотрим правде в глаза: в этих заполненных жесткими дисками корпусах размером с холодильник не мало «секретного соуса».

В каждом таком шасси имеются объединительные платы (бэкплейны) SAS и SATA, интерфейсы, контроллеры и некое специальное ПО, с помощью которого диски разбиваются на логические разделы. Большинство таких контроллеров работает под управлением одной из патентованных версий UNIX или даже производных BSD, которые вы никогда не сможете увидеть. Производители систем хранения скрывают их от вас, предоставляя вам только свои утилиты.

В большинстве случаев системы SAN или NAS после того, как вы нарезали разделы и предоставили серверу номера логических устройств, становятся для вас черными ящиками.

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

Говоря о гипермасштабирумости, я имею в виду Amazon Web Services, Microsoft Azure и Google Compute Engine. Вы же не думаете, что Amazon, Microsoft и Google могли бы снижать цены на облачное хранение, если бы использовали решения EMC и NetApp, не так ли? Конечно, нет. В этом случае они разорились бы.

Вместо устройств SAN и NAS гипермасштабируемые провайдеры на протяжении многих лет используют в основном простые массивы дисков (Just a Bunch of Disks, JBOD). В отличие от средних и крупных предприятий провайдеры гипермасштабируемых облаков создают собственные архитектуры хранения из массово выпускаемых компонентов с помощью JBOD и приобретенного ими инженерного опыта с целью намного снизить стоимость хранения по сравнению с корпоративными системами.

«Секретный соус» для архитектуры хранения на базе устройств потребительского класса по большей части не стандартизирован. Его недостатки связаны также с тем, что одним из главных препятствий на пути к такой архитектуре было использование оптоволокна для создания кластеризованной системы хранения, которое было все еще дорогим.

Однако благодаря конвергированным сетям 10Gigabit и 40Gigabit Ethernet, специализированным сетевым Ethernet-картам удаленного прямого доступа к памяти (Remote Direct Memory Access, RDMA) и появлению протокола сетевого хранения SMB 3.0 ситуация начинает быстро меняться.

Концепция довольно проста: подключить несколько файл-серверов к имеющейся коммутационной матрице Ethernet и использовать множество JBOD (таких, как выпускаемые компаниями DataOn, Dell или Supermicro), укомплектованных традиционными дисками SAS 15K и SSD и образующих многоуровневую конфигурацию.

Файл-серверы, в свою очередь, подключаются к хостам виртуализации или к физическим системам, которые предоставляют доступ к данным по протоколу SMB 3.0. Устойчивость встроена в операционную систему, обеспечивающую хранение, а не в некий патентованный «секретный соус» для контроллеров устройства хранения, как в случае с SAN или NAS.

В приведенном выше примере я использую файл-сервер Microsoft Scale-out File Server (SoFS), который бесплатно включен в состав Windows Server 2012 R2 и базируется на Microsoft Storage Spaces — программно-конфигурируемом хранении, встроенном в операционную систему. В данном сценарии использованы СХД DataOn DNS-1660D в сочетании с массово выпускаемыми стоечными серверами Dell R820 и RDMA-платами Mellanox. Описанная конфигурация способна обеспечить производительность свыше 1 млн. IOPS.

Dell также опубликовала документ, в котором говорится, как создать SoFS, используя массивы MD1220 PowerVaultJBOD. Но очевидно, что любое сочетание JBOD и массовых серверов x86 с использованием SAS и 10Gbps Ethernet, соответствующее этим базовым архитектурным принципам, должно работать.

Помимо Microsoft с ее SoFS и Storage Spaces есть и другие производители, придерживающиеся сходной архитектуры хранение на базе JBOD, такие как Nexenta (на основе Solaris ZFS). Для Linux имеются HA-LVM и GFS/GFS2, которые корпорация Red Hat поставляет с надстройкой Resilient Storage. Есть эквивалент для Ubuntu Server под названием ClusterStack. Если вам нужна архитектура программно-конфигурируемого хранения для Linux, более подготовленная к внедрению, вам следует изучить QuantaStor компании OSNEXUS.

Итог следующий. Хотя SAN и NAS являются проверенными и надежными, их гегемонии в обеспечении наивысшей производительности и надежности хранения данных в расчете на доллар приходит конец.

Если вы разумный руководитель, который пытается сократить постоянно растущие расходы на хранение данных, начинайте присматриваться к тому, что делают гипермасштабируемые облачные провайдеры, — используйте JBOD и функционал программно-конфигурируемого хранения, встроенный в современные серверные операционные системы, и применяйте Cloud Integrated Storage для приложений, у которых нет необходимости в хранении на съемных носителях, как и для тех, которые могут хранить архивные данные в облаке.

Версия для печати (без изображений)