[Перевод] Анархия и хранение данных: есть ли будущее у SAN
Примечание переводчика: Не так давно эксперт издания ZDnet Робин Харрис опубликовал материал о том, «почему SSD устарели» (в нашем блоге скоро выйдет его адаптированная версия). Другой эксперт издания Джейсон Перлоу решил, оттолкнувшись от этой статьи, порассуждать о минусах и перспективах сетевых систем хранения данных (SAN и NAS) — он считает, что будущее за подходом облачных провайдеров и использованием JBOD.Представленный ниже материал содержит значительное количество технических терминов, при переводе которых могут возникнуть неточности. Если вы заметили опечатку, ошибку или неточность перевода — напишите нам, и мы оперативно всё исправим.
Важно понимать, что используемые в настоящий момент интерфейсы SAS и SATA — не более, чем эволюционировавшие технологии SCSI и ATA, которые развиваются на протяжение десятилетий. С тех пор серверные технологии ушли далеко вперед, а потребность в приложениях для обработки данных значительно увеличилась.
Очевидно, что представители индустрии должны задуматься о дальнейшей модернищации существующих технологий хранения данных. Однако, задача по выжиманию большего количества IOPS из SSD больше относится к науке, с практической точки зрения куда важнее вопрос общей стоимости владения средствами хранения данных.
В больших компаниях все острее стоит вопрос организации хранения данных — особенно в регулируемых отраслях, участники которых обязаны хранить данные на протяжении длительного времени согласно законодательным нормам. Кроме того, эта информация должна быть легкодоступна — это усложняет использование технологий архивирования.
Говоря прямо, SAN и NAS стоят кучу денег, и на них уходит до трети всех затрат на «железо» в дата-центрах компаний. Да, производители таких продуктов заработали себе отличную репутацию, поэтому их продукцию используют для хранения самых критически важных данных, но давайте будем честны — в этих забитых дисками коробках размером с рефрижератор нет никакой магии.
Внутри все те же SATA, SAS, различные интерфейсы, контроллеры и специальный софт, который отвечает за создание логических номеров устройств (LUN). Большинство этих контроллеров работают на проприетарных версиях UNIX или даже разновидностях BSD — пользователь никогда ничего из этого не увидит. Для него SAN или NAS после создания LUN — это настоящий черный ящик.
Этому дорогущему безумию можно положить конец, но для этого необходим нестандартный и креативный подход представителей крупного бизнеса — это значит, что они должны относиться к хранилищу также, как это делают поставщики масштабируемых услуг (hyperscale). Когда мы говорим о масштабировании, то подразумеваем Amazon Web Services, Microsoft Azure или Google Computer Engine.
Вы же думаете, что этим компаниям удалось создать облачные системы хранения данных исключительно с помощью железа EMC и NetApp?
Конечно же нет, это просто невозможно. Вместо SAN и NAS такие компании используют JBOD — массивы «просто дисков» (Just a Bunch of Disks). Им удалось создать более дешевую инфраструктуру с помощью общедоступного и недорогого оборудования, JBOD и опытных инженеров.
Не существует никаких стандартов построения таких инфраструктур, к тому же этот процесс осложняется тем фактом, что исторически сложилось мнение о необходимости использования оптоволокна для создания кластеризованных хранилищ —, а это до сих пор очень затратно.
Однако благодаря Ethernet-сетям 10Gigabit и 40Gigabit, Ethernet-картам RDMA и появлению сетевого протокола доступа SMB 3.0 ситуация быстро меняется.
Концепция довольно проста — организация просто подключает множество «голов» файловых серверов к имеющейся скоммутированной Ethernet-инфраструктуре, и использует множество JBOD (их делают, к примеру, DataOn, Dell или Supermicro), составленных из SAS 15K и SSD, в ярусной конфиругации и соединенных с этими «головами» в SAS-кластере.
В свою очередь эти якорные файл-серверы соединены с виртуализированными или физическими системами, которые обеспечивают доступ к данных с помощью SMB 3.0. Эластичность такой системы зависит от ОС, управляющей хранилищем, а не от какого-то секретного софта, встроенного в контроллеры, как это сделано в SAN и NAS.
В сценарии, который описан на изображении выше, использованы файл-серверы Microsoft Scale-out File Server (SoFS), которые поставляются с встроенной Windows Server 2012 R2, и используют для работы компонент Storage Spaces. В качестве железа здесь задействованы DataOn DNS-1660D в комбинации со стоечными серверами Dell R820 и картами Mellanox RDMA.
Описанная выше конфигурация способна достигать постоянной скорости более 1 млн IOPS в секунду.
Публикацию о построении SoFS-массивов JBOD с помощью MD1220 PowerVault выпустила Dell. В общем-то, работать будет любая комбинация JBOD, распространенного железа архитектуры x86 с использованием SAS и Ethernet-соединения 10 Гбит/с.
Помимо Microsoft существуют и другие вендоры, занимающиеся построением архитектур, основанных на JBOD — например, Nexenta (на основе ZFS от Solaris), для Linux есть HA-LVM и GFS/GFS2, включающие компонент Resilient Storage от Red Hat. Эквивалент для Ubuntu Server называется ClusterStack.
Вывод здесь заключается в том, что несмотря на надежность и проверенность решений SAN и NAS их гегемония в деле обеспечения наивысшей производительности и «упругости» хранилищ подходит к концу, и скоро широко будут распространены и другие инструменты.
Руководители компаний, которые стремятся сэкономить на хранении все возрастающего объёма данных уже в ближайшем будущем могут прибегнуть к способу, который применяют облачные провайдеры — использованию JBOD и software defined storage (про это, кстати, на Хабре была статья), встроенных в современные серверные ОС, и применению хранилищ, интегрированных с облаком (CIS) для тех приложений, которым позволительно хранение бэкапов в облаке.
