Для корректного отображения этого элемента вам необходимо установить FlashPlayer и включить в браузере Java Script.
+7 (495) 775-33-76




Дисковые Массивы

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

Производительность дисковых массивов
Все зависит от приложения
  1. Выбор внешнего интерфейса
  2. Размер кэша контроллера
  3. Интерфейс жестких дисков

Позиционирование дисковых массивов
Полезные ссылки

Помощь консультанта

Основными элементами массива являются:
1) Внешний интерфейс (обычно это интерфейс RAID контроллера массива): NAS, SCSI, Fibre Channel, iSCSI
2) Кэш контроллера
3) Интерфейс жестких дисков массива: sATA, SCSI, Fibre Channel

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

Производительность дисковых массивов


Производительность можно рассматривать как показатель объема работы, выполненной за определенный промежуток времени. Производительность хранилищ данных часто выражается в числе операций ввода/вывода за секунду (IOPS) и/или мегабайт в секунду (MB/s). Число операций ввода/вывода за секунду (IOPS) и/или количество переданных мегабайт информации в секунду (MB/s) являются показателями производительности, но не ее синонимами, более того, они имеют обратную зависимость - большое значение показателя IOPS означает низкое MB/s, как показано на диаграмме:


Например, приложение требует 1 000 IOPS при размере блока в 8k, что равнозначно пропускной способности в 8 Мб/с (1 000 IOPS x блок 8k = 8 Мб/с). При использовании 200 Мб/с соединения Fibre Channel, 8 Мб/с уже не представляется слишком хорошей производительностью (8 Мб/с подразумевает использование только 4% пропускной способности шины Fibre Channel) если говорить о производительности в показателях Мб/с. Однако если приложение запрашивает 1 000 IOPS и устройство хранения данных предоставляет 1 000 IOPS без организации очереди (глубина очереди команд < 1), то можно говорить, что хранилище обслуживает приложение без задержек, что означает, что производительность на самом деле высока.

С другой стороны, если приложение видеомонтажа последовательно читает данные при размере блока 64 Мб и 3 параллельных потоках, это означает 192 Мб/сек общей производительности в 200 Мб/с соединении Fibre channel (64 Мб x 3 потока = 192 Мб/с). И, хотя нет никаких сомнений, что производительность 192 Мб/с высока (используется 96% пропускной способности шины Fibre Channel), следует отметить, что в данной среде приложения поддерживается всего лишь 3 IOPS.

Эти два простых примера наглядно иллюстрируют зависимость производительности от ситуации, т.е. производительность зависит от того, чего вы пытаетесь достичь - Мб/с или IOPS.

Все зависит от приложения


Не важно, какими возможностями обладает хранилище данных, оно не может предоставить большее число операций ввода/вывода, чем запрашивает приложение, поэтому именно приложение формирует и задает производительность. Например, предположим, что приложение генерирует запрос на 2 500 IOPS от хранилища. Существует ли какая-нибудь разница в производительности на уровне приложения между хранилищем, предоставляющим 2 500 IOPS и 10 000 IOPS? Очевидно, что ответом на вопрос является четкое "нет", поскольку любое хранилище может предоставить 2 500 IOPS по запросу. Это можно сравнить с ведением машины на автостраде с ограничением скорости: если все машины начинают движение в одно и то же время и придерживаются ограничения по скорости, то любая машина доставит вас в назначенное место в одно и то же время, вне зависимости от ее марки - будь это Chevy Lumina или Ferrari F40.

Производительность зависит от ситуации, то есть от того, чего вы пытаетесь достичь. Слишком многие производители систем хранения данных стремятся опубликовать производительность I/O в показателях пропускной способности (Мб/с). Большинство бизнес приложений ориентированы на транзакции и наиболее важным показателем производительности для них является именно число операций ввода/вывода в секунду (IOPS). В конечном счете, производительность может считаться хорошей, если приложение не ожидает очереди в хранилище. Понимание требований к рабочим характеристикам приложения и обеспечение соответствующим хранилищем, позволяет достичь максимальной производительности и эффективности приложения. Будьте внимательны к требованиям производительности - если среда, генерирующая требования не идентична и сильно отличается от вашей, вы не сможете получить те же результаты производительности. Единственный проверенный и надежный способ увидеть реальную производительность - определить ее в вашей среде приложения.

1. Выбор внешнего интерфейса


Еще лет 5 назад все было проще. Были RAID массивы, с 6 - 9 дисками со SCSI интерфейсом и все. За последние четыре года появились еще как минимум три интерфейса. Это Fibre Channel (FC), Gbit Ethernet NAS (Network Attached Storage, iSCSI (SCSI over IP). Массивы с интерфейсом SCSI, все еще остаются популярным решением для расширения объемов дискового пространства индивидуальных серверов.
Итак, осмелимся ввести несколько правил выбора внешнего интерфейса.

NAS (Network Attached Storage)

Выбирайте NAS, когда вам необходимо быстро и без особых хлопот добавить дисковое пространство в локальной сети для клиентов сети. Доступ к NAS устройствам осуществляется по локальной сети на уровне протоколов передачи файлов (NFS, CIFS), так как, по сути, это файловый сервер с 8 - 12 дисками hot swap, с 1 или 2 портами Gbit Ethernet, поддерживающий основные уровни RAID. От обычного сервера его отличает его собственная операционная система (обычно урезанный производителем Linux в Flash Memory), поддержка одновременно клиентов различных ОС (Windows, Linux, Solaris, Macintosh и т.д.), простота инсталляции (обычно до получаса). Еще одно преимущество NAS - он не требует пользовательских лицензий.

NAS следует использовать для хранения файлов клиентов сети. По статистике NAS обходится на 30% дешевле обычного файл сервера в сети. Он не требует пользовательских лицензий. Он поддерживает гетерогенные платформы. Он оптимизирован под файловый ввод/вывод.

NAS не следует использовать
  • В качестве дискового хранилища для серверов приложений и файловых серверов локальной сети
  • В качестве хранилища для back-up на диск (допускается в случае, если back-up делается в нерабочее время).

    На рисунках ниже приведены несколько примеров использования NAS:


    Рис. 2: Применение NAS устройства компании Axus Microsystems емкостью 2 терабайта в локальной сети с гетерогенными клиентами. Типовые приложения: отдел программирования, отдел проектирования CAM/CAD, отдел анализа медицинских изображений и данных, дизайнерский отдел т.д.

    Рис. 3: Местная (в пределах здания) или удаленная (через WAN) IP репликация томов серверов A, B и С с использованием NAS устройств sNAZ S8 компании Raidtec.

    Устройства на рис. 1 и 2 применяют соответственно АТА и sATA диски в качестве носителей.

    SCSI

    Используйте дисковые массивы с интерфейсом SCSI когда требуется увеличить дисковое пространство индивидуального сервера и вынести его за корпус.
    SCSI массивы не следует использовать, если вы, в недалеком будущем, планируете перейти на сеть хранения данных (SAN).


    Рис 4: Подключение кластера из двух узлов к высокопроизводительному массиву SANnet II Ultra 320 SCSI. Пример для сред с высокой плотностью транзакций. Области применения: биллинг, CRM, ERP и т.д.


    Рис 5: Подключение 4х терабайт внешнего дискового пространства к серверу архива документов с использованием дискового массива Demon SA16 Ultra 320 SCSI, компании Аxus Microsystems. Области применения: расширение дискового пространства NAS устройств, электронный архив, документооборот, video on demand, disk-to-disk back-up.

    Fibre Channel (FC)


    Используйте дисковые массивы с интерфейсом FC, когда вам необходимо подключить к нему несколько серверов приложений или клиентов которые будут делить его дисковое пространство между собой. Выбирайте массив исходя из требований вашего приложения.
      Массивы с интерфейсом FC следует использовать для серверов:
    • Oracle, Sybase, SQL, DB2, Informix и других баз, любящих быстрые диски
    • Высокопроизводительных приложений таких как: документооборот, B2C, billing, хранилищ корпоративных данных.
    • Требующих безотказный доступ к данным (24 х 7)
    • Серверов back-up, когда back-up делается через SAN.
    • Для станций видеомонтажа и серверов вещания
    • В корпоративных средах, для централизации всех ресурсов хранения в целях централизованного менеджмента, дублирования и защиты.
      Массивы с интерфейсом FC не следует использовать:
    • Для Web серверов.
    • Для DNS, WINS, DC, PDC
    • Для Desk Top PC (если это не станция видео монтажа)
    • Для серверов не требующих более 100GB пространства
    • Для серверов требующих разделение файловых ресурсов. Для этого лучше использовать NAS


    Рис 6: Построение высокопроизводительной, отказоустойчивой (99,9998%) сети хранения данных, для приложений с высокой плотностью транзакций (до 160 000 IOPs) с использованием массива SANnet II FC-FC от DotHill. (6 серверов, 2 FC switch, 2 DotHill, no-single point of failure). Области применения: hot billing, телекоммуникации, моделирование в реальном времени, CRM, ERP, банковские и финансовые системы, большие высокотранзакционные базы данных.


    Рис 7: Использование контроллера хранения данных RIO для построения корпоративной сети хранения данных с иерархическим менеджментом. К контроллеру RIO подключен JBOD c дисками FC емкостью 2 терабайта и три JBOD с sATA дисками, емкостью 4 терабайта каждый. Иерархический менеджер отслеживает частоту доступа к данным и мигрирует реже используемые данные на sATA диски. Области применения: документооборот в крупных компаниях, электронный архив, библиотечные системы, ТВ студии и вещание, студии нелинейного монтажа.

    Рис. 8: Использование дисковых массива RIVA FC-FС и Stratis FC-SCSI для построения сети хранения данных небольшого предприятия или подразделения для приложений со средней плотностью транзакций (до 64 000 IOPs). Области применения: cold billing, e-business, потоковый видео, небольшой банк.

    Рис. 9: Использование дискового массива Demon SA16-FC-sATA в качестве недорогого и емкого хранилища с sATA дисками для архивных и файл серверов, студий нелинейного монтажа, disk-to-disk back-up через SAN, расширение дискового пространства NAS.

    iSCSI: Этот раздел в стадии разработки.
    Ниже приведены графики массивов, предлагаемых Storus в зависимости от интерфейса, производительности, цены и области применения.

    Рис. 10: Позиционирование дисковых массивов SCSI

    Рис. 11: Позиционирование дисковых массивов FC (на 4 терабайта)

    2. Размер кэша контроллера


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

    Существует два типа доступа к данным со стороны приложения: последовательный (видео, большие файлы, и т.д.), когда данные пишутся на диск большими порциями (блоками), и ложатся на поверхность последовательно, и случайный (базы данных с записями малых размеров, высокотранзакционные приложения), когда данные пишутся на диск малыми порциями и разбросаны по всему дисковому пространству массива. Легко предположить, что при запросе на чтение, в первом случае контроллер соберет данные быстрее, т.к. блоки расположены рядом и время позиционирования головок диска минимально. Во втором случае, головкам диска необходимо совершить гораздо больше <телодвижений>, чтобы собрать разрозненные крошечные <кусочки>. С другой стороны, доступ в кэш, который является оперативной памятью, гораздо быстрее, чем к диску. Алгоритмы кэширования работают одинаково (с некоторой разницей в эффективности, в зависимости от производителя): наиболее часто запрашиваемые данные хранятся в кэш.

    Поэтому мы можем предположить, что размер кэш памяти контроллера, прежде всего, критичен для приложений со случайным доступом, которые характеризуются высокой плотностью транзакций в единицу времени. Увеличение кэш памяти контроллера в двое может повысить производительность системы в целом на 35% (!). Если для потокового видео вполне будет достаточно 128 МВ, то для системы потребуется не менее 1GB

    3. Интерфейс жестких дисков


    Storus предлагает дисковые массивы с дисками Fibre Channel, SCSI и sATA.
      FC HDD:
    • Надежность высокая. Каждый диск снабжен двумя каналами FC. В случае выхода из строя одного, работа продолжается по второму. 1 500 000 часов наработки на отказ.
    • Производительность отличная. Наивысшая производительность для приложений со случайным методом доступа.
    • Масштабируемость отличная. Емкость массива наращивается до 60 терабайт.
      SCSI HDD:
    • Надежность средняя. Каждый диск имеет один канал. В случае выхода из строя подлежит замене. 1 000 000 часов наработки на отказ.
    • Производительность хорошая. Для приложений со случайным методом доступа.
    • Масштабируемость плохая. Емкость массива наращивается до 4 терабайт.
      SATA HDD:
    • Надежность ниже средней. Не для массивов с интенсивным циклом. Наработка на отказ 500 000 часов.
    • Производительность средняя. Хорошая для приложений с последовательным методом доступа.
    • Масштабируемость отличная. До 120 терабайт в одном массиве.

    Полезные ссылки:


    1) В обзоре рассматриваются достоинства и недостатки нтерфейсов систем хранения данных таких как: SCSI, Fibre Channel, IEEE 1394 (FireWire), Serial ATA и iSCSI.
    storage_interfaces.pdf
    2) Исследование, проведенное аналитической компанией Taneja Group, предсказывает перспективы использования в ярусном хранении (tiered storage) дисков ATA и Serial ATA. В статье также дано описание ярусов хранения (storage tiers), представлены 4 ключевых фактора, влияющих на развитие данной технологии и мнения Taneja Group по поводу будущего технологии.
    Storage-Tiers-ATA-Tech-Brief-01-2004.pdf
    3) В этой статье рассматриваются различные методы подключения хранилищ к хост системам, такие как SAS (DAS), NAS и SAN, а также варианты организации резервного копирования, используемые в каждом случае.
    host_connection_1.htm
    4) Производители дисковых систем часто обращают внимание на "внутреннюю пропускную способность" дисковых систем. Является ли она полезным показателем производительности для приложений? Можно ли использовать это показатель для сравнения производительности двух различных дисковых систем? Ответы на эти вопросы обсуждаются в настоящей статье
    DiskSystemInternalBandwidthWars.pdf



  • © Copyright "СТОРУС" 2003 - 2017