Введение в системы хранения данных

Введение в системы хранения данных

Цель статьи – рассмотреть концептуальные основы подходов к построению систем хранения данных. Здесь намеренно не приводится технических характеристик, т.к. к сути они отношения не имеют. Дабы статья не выглядела рекламной брошюрой, не будет и названий продуктов, а также степеней «хороший» и «не имеющий аналогов». Исчерпывающей статью также назвать нельзя, наоборот, я постарался охватить минимально-достаточный материал, доступный для понимания среднему инженеру, никогда не имевшему дело с СХД. Итак, начнем.

DAS (Direct Attached Storage)

Эта вещь вам давно знакома. Вспомним схему работы с диском обычного PC: материнская плата соединяется с HDD посредством интерфейсов ATA/SATA. Вы уже давно все это знаете, а значит представляете, что такое DAS. Точнее, вы понимаете, что такое архитектура DAS внутреннего типа. Существует также архитектура DAS внешнего типа, которая отличается от внутренней допустимым расстоянием между, вообще говоря, несколькими серверами и устройством хранения.

Введение в системы хранения данных-01

Введение в системы хранения данных-01

Возможность внешнего подключения достигается благодаря использованию технологий SCSI и FC. Если не вдаваться в детали перечисленных технологий передачи данных, это, пожалуй, все, что можно сказать про DAS.

Из принципиальной простоты архитектуры DAS следуют основные ее преимущества: наименьшая цена по сравнению с остальными, рассмотренными ниже и относительная простота внедрения. Кроме того, такой конфигурацией легче управлять ввиду хотя бы того, что число элементов системы мало. Целостность данных в DAS обеспечивается применением старой и популярной технологии RAID.
Однако такое решение подойдет для относительно некритичных задач и ограниченного числа рабочих станций. Совместное использование конечных вычислительных ресурсов накладывает ряд ограничений. Количество одновременно подключенных машин не превышает числа портов в устройстве хранения, ограниченная пропускная способность увеличивает время чтения-записи (IO), неэффективное использование кеша и т.д.

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

Введение в системы хранения данных-02

Введение в системы хранения данных-02

Однако и у этой схемы начинаются трудности, когда возникает необходимость разделять данные между серверами, или объем занимаемой памяти оказывается неравномерным. Очевидно, что в таких условиях DAS не отвечает требованиям масштабируемости и отказоустойчивости, по этой причине были придуманы NAS и SAN.

NAS (Network Attached Storage)

Представим себе сервер в локальной сети, который не делает ничего, кроме как расшаривает свои папки. Это практически и есть NAS. Да, NAS – это всего лишь устройство для файлового обмена в IP сети. Минимальная конфигурация NAS выглядит так:

Введение в системы хранения данных-03

Введение в системы хранения данных-03

О структуре. NAS-устройство (файл-сервер) – это выделенный высокопроизводительный сервер, имеющий собственную ОС, оптимизированную для операций чтения/записи. Сервер имеет несколько сетевых интерфейсов для связи с IP сетью и устройством хранения: GigabitEthernet, FastEthernet, FDDI и проч. Кроме того, NAS обладает большим объемом оперативной памяти, большая часть которой используется как кеш, что позволяет выполнять операцию записи асинхронно, а чтение ускорить за счет буферизации. Таким образом, данные могут долгое время находится в оперативной памяти, не попадая на диск.

Storage (дисковый массив) – то, что чаще всего изображается в статьях, где речь идет о дата-центрах. Другими словами это шкаф (стойка) с дисками, соединенный (или интегрированный) с файл-сервером. Интегрированный? Да, NAS может быть отдельным сервером (как на рисунке) или входить в состав цельного устройства. В первом случае имеем дело с gateway реализацией NAS, во втором – с монолитной системой. О gateway реализации мы еще вспомним, когда будем говорить о SAN.

Как работает NAS? NAS поддерживает работу с протоколами шаринга CIFS и NFS. Клиент монтирует у себя файловую систему, предоставляемую NAS'ом и выполняет операции чтения/записи в обычном файловом режиме, а сервер NAS их обрабатывает, переводя на язык блочного доступа, понятный стораджу. Кроме этого, поддерживаются такие протоколы, как FTP, DFS, SMB и т.д.Вот и весь NAS… быстро и вкусно.

Какой профит от использования NAS и почему типовому решению нужно отводить целый класс? Во-первых, операции IO занимают меньше времени, следовательно, NAS работает существенно быстрее, чем сервера «общего назначения», так если в вашей архитектуре есть сервер, который должен отдавать много статики, стоит подумать об использовании NAS. Во-вторых, централизованное хранение проще в управлении. В-третьих, общее увеличение емкости NAS происходит прозрачно для клиентов, все операции добавления/удаления памяти скрыты от потребителей. В-четвертых, предоставление доступа на уровне файловой системы позволяет вводить понятие привилегий rwx. Забегая вперед, можно отметить, что при помощи NAS без ущерба пропускной способности легко организовать мультисайтововсть (о том, что это такое мы расскажем, когда речь пойдет о репликации).

Но есть и ряд ограничений, связанных с использованием NAS. В основном это связано с базовым для NAS принципом. Сама по себе избыточность TCP/IP как протокола доступа к данным приводит к накладным расходам. Высокая нагрузка на сеть с довольно ограниченной пропускной способностью увеличивает время отклика. Производительность системы в целом зависит не только от NAS, но и от качества работы коммутирующих устройств сети. Кроме того, без правильного resource allocation, клиент, запрашивающий слишком большие объемы файлов, может влиять на скорость работы других клиентов

SAN (Storage Area Network)

Здесь аналогии с enthernet я не придумал :(. SAN (сеть хранения данных) – это инфраструктура блочного хранения данных, построенная на базе высокоскоростной сети.

Как видно из определения, основное отличие от NAS заключается в предоставлении доступа к данным на блочном уровне. Если же сравнивать SAN и DAS, ключевым понятием здесь является сеть. Так, среди основных компонентов SAN те же компоненты, но от прочих архитектур ее отличает наличие специальных коммутаторов, поддерживающих передачу данных по FibreChannel или (Fast- GB- etc.) Ethernet:

Введение в системы хранения данных-04

Введение в системы хранения данных-04

История SAN начинается с конца 1980-х, когда впервые была предложена идея построения FC сети. В ранних реализациях в качестве коммутирующего устройства использовались хабы, такой подход называется управляемой петлей (Arbitrated Loop, далее FC-AL):

Введение в системы хранения данных-05

Введение в системы хранения данных-05

Схема взаимодействия в FС-AL аналогична CSMA/CA: каждый раз, когда какой-либо узел в FC-AL собирается выполнить операцию IO, он посылает блокирующий пакет, оповещая всех о начале передачи. Когда пакет возвращается отправителю, узел получает полный контроль над петлей для проведения операции. По окончанию операции все узлы оповещаются об освобождении канала и процедура повторяется. Очевидно, что такая ситуация ничем не лучше DAS, а к проблемам пропускной способности добавляется еще одна: в каждый момент времени только один клиент может выполнять операцию IO. Кроме того, использование 8-битной адресации в FC-AL позволяет иметь не более 127 устройств в сети. Короче говоря, FС-AL оказался ничем не лучше DAS.

На смену FC-AL пришла архитектура, название которой я не стану переводить: FC-Switched Fabric (FC-SW). Именно эта реализация SAN дошла до наших дней. В FC-SW вместо хаба используется один или несколько коммутаторов, таким образом данные предаются не по разделяемому, а по индивидуальным каналам.
Как и в Ethernet на базе этих коммутаторов можно построить множество топологий, в частности, к корневому (-ым) может быть подключен другой коммутатор или хаб:

Введение в системы хранения данных-06

Введение в системы хранения данных-06

Преимущества SAN очевидны:
общий объем памяти может расти не только за счет увеличения емкости существующих сторожей, но и за счет добавления новых;
каждый хост может работать с любым устройством хранения, а не только со своим, как в случае с DAS;
сервер имеет несколько «путей» получения данных (multipathing), поэтому, при правильно построенной топологии, даже после выхода из строя одного из коммутаторов система останется рабочей;
есть такая опция, как Boot From SAN, это означает что серверу теперь даже не нужен собственный загрузочный диск;
существует опция zoning, позволяющая разграничивать доступ серверов к ресурсам;
отчасти решена проблема с пропускной способностью – отчасти, т.к. узким местом по-прежнему остается канал между устройством хранения и коммутатором, однако, такие операции, как например резервное копирование не оказывают влияния на всю сеть.

Еще одно важное преимущество SAN, о котором нужно сказать отдельно. Гибкая архитектура и предоставление доступа на блочном уровне позволяют построить множество различных решений в зависимости от задачи. Например, если мы снабдим один из серверов специальной ОС, мы получим не что иное, как gateway-реализацию NAS (см. рис. выше), таким образом в рамках решения для одного предприятия могут сочетаться и DAS, и NAS, и SAN.

Но нельзя без ложки дегтя. Один из главных недостатков SAN – это цена. Оставим цифры маркетологам, отметим только что SAN могут себе позволить далеко не все.

Вместо заключения

Очень кратко были рассмотрены основные подходы к построению систем управления данными. Здесь не затронуты такие понятия, как IP SAN или CAS, ничего не сказано про iSCSI и про технологии передачи в целом – пока оставим это для самостоятельного чтения.
Очень поверхностно сказано о защите данных от потерь, способах резервного копирования, что делать, если сгорел датацентр, короче говоря о внештатных ситуациях (disasters) – они-то и станут предметом нашего следующего обзора

Материал сайта pyatilistnik.org.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

я в гугл