Есть ли среди СХД те, у которых риск потери данных выше?
Чем ниже класс решения, тем выше риски потери данных, и наоборот. Зачастую компании, которые только начинают расти, используют решения Entry Level. Поначалу все идёт хорошо, но потом возникают вопросы: а что, если сломается контроллер? Как его менять? Что делать, если нужен рост производительности? В связи с этим решение меняется на уровень Enterprise, с более низкими рисками потери данных. «В наших решениях используются диски, в которых может быть до 12 контроллеров, и даже если четверть из них выйдет из строя, данные останутся неповрежденными», – отмечает Алексей Никифоров.
Однако при всех достижениях в технологиях защиты данных, нужно учитывать, что далеко не для каждой компании риски их потери могут быть критичными. Если в организации хранятся данные, которые «не жалко», то и беспокоиться по поводу надежности системы лишний раз не стоит.
SDS
Software-defined storage — программно определяемое хранилище данных, основанное на DAS, при котором дисковые подсистемы нескольких серверов логически объединяются между собой в кластер, который дает своим клиентам доступ к общему дисковому пространству.
Наиболее яркими представителями являются GlusterFS и Ceph, но также подобные вещи можно сделать и традиционными средствами (например на основе LVM2, программной реализации iSCSI и NFS).
Пример SDS на основе GlusterFS
Из преимуществ SDS — можно построить отказоустойчивую производительную реплицируемую систему хранения данных с использованием обычного, возможно даже устаревшего оборудования. Если убрать зависимость от основной сети, то есть добавить выделенные сетевые карты для работы SDS, то получается решение с преимуществами больших SAN\NAS, но без присущих им недостатков. Я считаю, что за подобными системами — будущее, особенно с учетом того, что быстрая сетевая инфраструктура более универсальная (ее можно использовать и для других целей), а также дешевеет гораздо быстрее, чем специализированное оборудование для построения SAN. Недостатком можно назвать увеличение сложности по сравнению с обычным NAS, а также излишней перегруженностью (нужно больше оборудования) в условиях малых систем хранения данных.
Новые архитектуры хранилищ данных
Panoply
- Анализ запросов и данных — определение наилучшей конфигурации для каждого варианта использования, корректировка ее с течением времени и создание индексов, сортировочных ключей, дисковых ключей, типов данных, вакуумирование и разбиение.
- Идентификация запросов, которые не следуют передовым методам — например, те, которые включают вложенные циклы или неявное приведение — и переписывает их в эквивалентный запрос, требующий доли времени выполнения или ресурсов.
- Оптимизация конфигурации сервера с течением времени на основе шаблонов запросов и изучения того, какая настройка сервера работает лучше всего. Платформа плавно переключает типы серверов и измеряет итоговую производительность.
По ту сторону облачных хранилищ данных
Загрузка данных в облачные хранилища данных нетривиальна, а для крупномасштабных конвейеров данных требуется настройка, тестирование и поддержка процесса ETL
Эта часть процесса обычно выполняется сторонними инструментами;
Обновления, вставки и удаления могут быть сложными и должны выполняться осторожно, чтобы не допустить снижения производительности запросов;
С полуструктурированными данными трудно иметь дело — их необходимо нормализовать в формате реляционной базы данных, что требует автоматизации больших потоков данных;
Вложенные структуры обычно не поддерживаются в облачных хранилищах данных. Вам необходимо преобразовать вложенные таблицы в форматы, понятные хранилищу данных;
Оптимизация кластера
Существуют различные варианты настройки кластера Redshift для запуска ваших рабочих нагрузок. Различные рабочие нагрузки, наборы данных или даже различные типы запросов могут потребовать иной настройки. Для достижения оптимальной работы, необходимо постоянно пересматривать и при необходимости дополнительно настраивать конфигурацию;
Оптимизация запросов — пользовательские запросы могут не соответствовать передовым методам и, следовательно, будут выполняться намного дольше. Вы можете работать с пользователями или автоматизированными клиентскими приложениями для оптимизации запросов, чтобы хранилище данных могло работать так, как ожидалось
Резервное копирование и восстановление — несмотря на то, что поставщики хранилищ данных предоставляют множество возможностей для резервного копирования ваших данных, их нетривиально настроить и они требуют мониторинга и пристального внимания
Ссылка на оригинальный текст: panoply.io/data-warehouse-guide/data-warehouse-architecture-traditional-vs-cloud
2.10 Пример предоставления доступа к своему бакету другому пользователю с правом чтения только с указанного IP адреса используя S3 Bucket Policies
В нашей группе demo-cmc-grp-1, в дополнение к существующему demo-cmc-user-1 создадим еще одного пользователя: demo-cmc-user-2.
У пользователя demo-cmc-user-1, уже есть бакет demo-s3-bucket-1 (созданный ранее), а для пользователя demo-cmc-user-2 создадим бакет demo-s3-bucket-3.
Установим CLI и настроим два профиля для пользователя demo-cmc-user-1 и demo-cmc-user-2. И посмотрим список бакетов при помощи команд:
Запомним ID наших пользователей и какие бакеты у них есть:
-
demo-cmc-user-1, ea25fa386cf9a26db2fd8c9650de065d
-
demo-cmc-user-2, 86357359a3e5deb3daf86d0ead918d08
Теперь давайте дадим доступ пользователю demo-cmc-user-1 только на чтение и просмотр содержимого бакета созданного пользователем demo-cmc-user-2 и разрешим доступ только с IP адреса: 176.53.ХХХ.ХХХ. Т. к. править Bucket Policies в CMC нельзя, то будем использовать все тот же S3 Browser, использующий S3 API. Подключимся под demo-cmc-user-2 и для бакета demo-s3-bucket-3, назначим политику:
Теперь подключимся пользователем demo-cmc-user-1, используя S3 Browser и подключим внешний бакет:
За счет назначенных Action (действий) мы смогли получить доступ к бакету, просмотреть его содержимое и скачивать объекты.
Подобным способом мы можем назначить и другие действия на бакет.
Однако будьте внимательны с политиками и вначале проведите проверки на тестовых бакетах и работы вашего ПО, а потом на продуктовых. Особенно аккуратно применяйте политики к уже созданным бакетам с множеством объектов.
Давайте представим, что мы дали другому пользователю доступ к бакету не только на чтение, но и на запись. При такой схеме при загрузке объектов во внешний бакет владельцем бакета будет один пользователь, который его создал. А вот владельцем объекта внутри уже другой — тот, который его закачал.
Для первичной подготовки шаблона политики, удобно использовать AWS Policy Generator, а потом подправить полученный результат под свои требования.
Вот такие дела
Спасибо за внимание!. Что ещё интересного есть в блоге Cloud4Y
Что ещё интересного есть в блоге Cloud4Y
→ Как открыть сейф с помощью ручки
→ Сделайте Linux похожим на Windows 95
→ Как распечатать цветной механический телевизор на 3D-принтере
→ WD-40: средство, которое может почти всё
→ Взлёт и падение игрового чипа 6502
Подписывайтесь на наш Telegram-канал, чтобы не пропустить очередную статью. Пишем только по делу. А ещё напоминаем про второй сезон нашего сериала ITить-колотить. Его можно посмотреть на YouTube и .
Традиционная архитектура хранилища данных
Трехуровневая архитектура
- Нижний уровень: этот уровень содержит сервер базы данных, используемый для извлечения данных из множества различных источников, например, из транзакционных баз данных, используемых для интерфейсных приложений.
- Средний уровень: средний уровень содержит сервер OLAP, который преобразует данные в структуру, лучше подходящую для анализа и сложных запросов. Сервер OLAP может работать двумя способами: либо в качестве расширенной системы управления реляционными базами данных, которая отображает операции над многомерными данными в стандартные реляционные операции (Relational OLAP), либо с использованием многомерной модели OLAP, которая непосредственно реализует многомерные данные и операции.
- Верхний уровень: верхний уровень — это уровень клиента. Этот уровень содержит инструменты, используемые для высокоуровневого анализа данных, создания отчетов и анализа данных.
Модели хранилищ данных
- Виртуальное хранилище данных — это набор отдельных баз данных, которые можно использовать совместно, чтобы пользователь мог эффективно получать доступ ко всем данным, как если бы они хранились в одном хранилище данных;
- Модель витрины данных используется для отчетности и анализа конкретных бизнес-линий. В этой модели хранилища – агрегированные данные из ряда исходных систем, относящихся к конкретной бизнес-сфере, такой как продажи или финансы;
- Модель корпоративного хранилища данных предполагает хранение агрегированных данных, охватывающих всю организацию. Эта модель рассматривает хранилище данных как сердце информационной системы предприятия с интегрированными данными всех бизнес-единиц
Надёжность ЦОДа
- Отказоустойчивость. Это свойство технической системы сохранять свою работоспособность после отказа одного или нескольких составных компонентов.
- Высокая доступность. Это свойство системы определяет её надёжность, возможность выполнять требуемую функцию при заданных условиях в данный момент времени или в течение заданного интервала времени при соблюдении определенного набора условий.
- Непрерывность бизнеса. Она включает в себя процессы и методы, направленные на обеспечение безостановочного выполнение критичных бизнес-функций.
- Катастрофоустойчивость. Это способность к восстановлению после катастрофы т.е. устойчивость к воздействию аварий и природных катаклизмов.
Tier I (N) Tier II (N+1)Tier III (N+1)Tier IV (2(N+1))
Четыре уровня отказоустойчивости ЦОДа.
Какие бывают типы СХД?
Есть три больших типа систем хранения данных: файловое хранилище, объектное хранилище и блочное хранилище.
Блочное хранилище
Работает по блочным протоколам SAN: Iscsi и Fibre Channel. Они подключаются к серверам с нарезанием томов и файловых систем для дальнейшего использования. Блок данных – это не какой-то законченный объект, а кусок фиксированного размера, содержащий некие данные. Файл может занимать несколько блоков, и, если последний из этих блоков заполнен не до конца, на его размер это не повлияет. Блочное хранилище может быть использовано любой операционной системой в качестве дискового тома этой системы, а пользователь видит этот диск в интерфейсе ОС сервера. Она, в свою очередь, может быть как физической, так и виртуальной. Однако физическим серверам в отличие от виртуальных нужны дополнительные контроллеры для того, чтобы получать доступ к исходным блокам. Преимуществом блочных систем является высокое быстродействие.
Файловые хранилища
Могут работать как с конечными пользователями (например, сотрудниками, которые со своего компьютера могут открыть файлы компании), так и с серверными мощностями. Такие хранилища внешне больше всего напоминают организацию информации в наших компьютерах: файлы вложены в папки. Доступ к данным осуществляется по file ID, содержащему имя сервера, путь к директории, а также имя искомого файла в NAS. Чаще всего в качестве протоколов доступа к файлам через NAS используют протоколы NFS (для Unix и Linux) и CIFS (для Windows). Последний является публичным вариантом более специализированного протокола SMB (Server Message Block), который использует сетевой протокол TCP/IP. Сервер файловой СХД использует внутри локальной файловой системы блочное хранилище, в то время как пользователь работает лишь с внешним протоколом, определяющим путь к файлу.
Объектное хранилище
Можно использовать в разных целях. Основные его задачи – сохранять большие объемы данных в виде объектов, которые можно моделировать и которым можно присвоить метаданные. В СХД этого типа применяются примерно такие же технологии, что и в публичном облаке (HTTP, API). Объектные хранилища легко масштабируются до объемов петабайта в одном домене, без снижения производительности. В отличие от традиционных СХД, в объектных хранилищах есть функционал управления данными – например, кастомизации метаданных и встроенной аналитики. На внешнем уровне размещены средства управления, а на внутреннем уровне каждый диск форматируется простой локальной файловой системой (например, EXT4). Это позволяет пользователю управлять функциями внешнего уровня через стандартный интерфейс прикладного программирования API, а все элементы СХД интегрированы в единый унифицированный том.
Как выбрать СХД?
Выбор СХД зависит от нескольких критериев: это и объем компании, и ее бизнес-задачи, и тип системы. Если мы говорим о блочной СХД, то в первую очередь нужно определиться с тем, какие объемы данных будут на ней хранить, а также с тем, какая для этих объемов требуется производительность и какие требования по уровню надежности предъявляет заказчик. Иногда выдвигаются такие критерии, с которыми не могут справиться никакие решения, кроме большого SATA–райзера с дисками SSD. Соответственно, именно из них и следует выбирать. «Однако бывает, что у компании нет необходимости защищать решение даже от падения контроллера, – отмечает Алексей Никифоров. – В таком случае можно выбрать недорогую СХД и надеяться, что она будет работать без критических нарушений».
DAS (Direct Attached Storage)
Эта вещь вам давно знакома. Вспомним схему работы с диском обычного PC: материнская плата соединяется с HDD посредством интерфейсов ATA/SATA. Вы уже давно все это знаете, а значит представляете, что такое DAS. Точнее, вы понимаете, что такое архитектура DAS внутреннего типа. Существует также архитектура DAS внешнего типа, которая отличается от внутренней допустимым расстоянием между, вообще говоря, несколькими серверами и устройством хранения.
Введение в системы хранения данных-01
Возможность внешнего подключения достигается благодаря использованию технологий SCSI и FC. Если не вдаваться в детали перечисленных технологий передачи данных, это, пожалуй, все, что можно сказать про DAS.
Из принципиальной простоты архитектуры DAS следуют основные ее преимущества: наименьшая цена по сравнению с остальными, рассмотренными ниже и относительная простота внедрения. Кроме того, такой конфигурацией легче управлять ввиду хотя бы того, что число элементов системы мало. Целостность данных в DAS обеспечивается применением старой и популярной технологии RAID. Однако такое решение подойдет для относительно некритичных задач и ограниченного числа рабочих станций. Совместное использование конечных вычислительных ресурсов накладывает ряд ограничений. Количество одновременно подключенных машин не превышает числа портов в устройстве хранения, ограниченная пропускная способность увеличивает время чтения-записи (IO), неэффективное использование кеша и т.д.
Частично проблемы производительности могут быть решены парком серверов (например разделенные по типу обрабатываемых запросов), каждый из которых нагружает отдельное устройство хранения.
Введение в системы хранения данных-02
Однако и у этой схемы начинаются трудности, когда возникает необходимость разделять данные между серверами, или объем занимаемой памяти оказывается неравномерным. Очевидно, что в таких условиях DAS не отвечает требованиям масштабируемости и отказоустойчивости, по этой причине были придуманы NAS и SAN.
Зачем использовать хранилище iSCSI?
Помимо вышеупомянутых преимуществ iSCSI, таких как экономия затрат и высокая производительность, есть некоторые другие преимущества и недостатки iSCSI:
-
Поскольку iSCSI работает на сетевых компонентах Gigabit Ethernet (коммутатор Gigabit Ethernet, маршрутизатор и т. д.), он не только дешевле в использовании, но и упрощает среду сетевого хранения.
-
IT персоналу не требуется дополнительных навыков для работы с хранилищем iSCSI. Любой, кто знаком с технологией TCP/IP, может легко установить iSCSI SAN и управлять им.
-
Хранилище iSCSI основано на TCP/IP, который является универсальной и непатентованной технологией, поэтому различные фирменные сетевые устройства хранения данных в iSCSI SAN могут без проблем работать вместе.
-
Тем не менее, основным ограничением сетей хранения iSCSI является их производительность по сравнению со средами хранения на основе FC, но доступность iSCSI 10 GbE и других технических реализаций, таких как многопутевый переход и мостовое соединение центров обработки данных, помогли сократить разрыв в производительности.
Direct Attached Storage (DAS)
Системы хранения данных с прямым подключением (DAS) реализуют самый известный тип соединения. При использовании DAS сервер имеет персональную связь с СХД и почти всегда является единоличным пользователем устройства. При этом сервер получает блочный доступ к системе хранения данных, то есть обращается непосредственно к блокам данных.
Недостатком прямого способа подключения является небольшое расстояние между сервером и устройством хранения. Типичный интерфейс DAS — SAS 12Gbit. Системы хранения данных такого типа стали терять свою популярность и замещаться оборудованием с SAN подключением.
DAS
Direct Attached Storage — это исторически первый вариант подключения носителей, применяемый до сих пор. Накопитель, с точки зрения компьютера, в котором он установлен, используется монопольно, обращение с накопителем происходит поблочно, обеспечивая максимальную скорость обмена данными с накопителем с минимальными задержками. Также это наиболее дешевый вариант организации системы хранения данных, однако не лишенный своих недостатков. К примеру если нужно организовать хранение данных предприятия на нескольких серверах, то такой способ организации не позволяет совместное использование дисков разных серверов между собой, так что система хранения данных будет не оптимальной: некоторые сервера будут испытывать недостаток дискового пространства, другие же — не будут полностью его утилизировать:
Конфигурации систем с единственным накопителем применяются чаще всего для нетребовательных нагрузок, обычно для домашнего применения. Для профессиональных целей, а также промышленного применения чаще всего используется несколько накопителей, объединенных в RAID-массив программно, либо с помощью аппаратной карты RAID для достижения отказоустойчивости и\или более высокой скорости работы, чем единичный накопитель. Также есть возможность организации кэширования наиболее часто используемых данных на более быстром, но менее емком твердотельном накопителе для достижения и большой емкости и большой скорости работы дисковой подсистемы компьютера.
Как новые технологии влияют на развитие СХД?
СХД – это довольно классические решения, которые меняются эволюционно, а не революционно. Можно заметить изменения в интерфейсе: с 16 ГБит/c на 32 Гбит/c, если говорить про SAN, и с 6 Гбит/c на 12 Гбит/c, если говорить про SAS. Считается, что NVMe существенно понизит задержки и обеспечит точки роста, поэтому многие аналитики связывают с ним будущее СХД.
«Есть технология FCoE (Fibre Channel over Ethernet), – рассказывает Алексей Никифоров, директор по технологиям Hitachi Vantara в России и СНГ. – Многие продвигали эту технологию, были заявления о том, что она заместит SAN. Этого не произошло, и фактически технология не то чтобы умерла, но сейчас о ней уже никто не вспоминает».
SAN
Storage area network, она же сеть хранения данных, является технологией организации системы хранения данных с использованием выделенной сети, позволяя таким образом подключать диски к серверам с использованием специализированного оборудования. Так решается вопрос с утилизацией дискового пространства серверами, а также устраняются точки отказа, неизбежно присутствующие в системах хранения данных на основе DAS. Сеть хранения данных чаще всего использует технологию Fibre Channel, однако явной привязки к технологии передачи данных — нет. Накопители используются в блочном режиме, для общения с накопителями используются протоколы SCSI и NVMe, инкапсулируемые в кадры FC, либо в стандартные пакеты TCP, например в случае использования SAN на основе iSCSI.
Давайте разберем более детально устройство SAN, для этого логически разделим ее на две важных части, сервера с HBA и дисковые полки, как оконечные устройства, а также коммутаторы (в больших системах — маршрутизаторы) и кабели, как средства построения сети. HBA — специализированный контроллер, размещаемый в сервере, подключаемом к SAN. Через этот контроллер сервер будет «видеть» диски, размещаемые в дисковых полках. Сервера и дисковые полки не обязательно должны размещаться рядом, хотя для достижения высокой производительности и малых задержек это рекомендуется. Сервера и полки подключаются к коммутатору, который организует общую среду передачи данных. Коммутаторы могут также соединяться с собой с помощью межкоммутаторных соединений, совокупность всех коммутаторов и их соединений называется фабрикой. Есть разные варианты реализации фабрики, я не буду тут останавливаться подробно. Для отказоустойчивости рекомендуется подключать минимум две фабрики к каждому HBA в сервере (иногда ставят несколько HBA) и к каждой дисковой полке, чтобы коммутаторы не стали точкой отказа SAN.
Недостатками такой системы являются большая стоимость и сложность, поскольку для обеспечения отказоустойчивости требуется обеспечить несколько путей доступа (multipath) серверов к дисковым полкам, а значит, как минимум, задублировать фабрики. Также в силу физических ограничений (скорость света в общем и емкость передачи данных в информационной матрице коммутаторов в частности) хоть и существует возможность неограниченного подключения устройств между собой, на практике чаще всего есть ограничения по числу соединений (в том числе и между коммутаторами), числу дисковых полок и тому подобное.
Как выбрать СХД?
В первую очередь нужно понимать, какие задачи она будет решать
Важно определиться с несколькими базовыми параметрами
Тип данных
Разные типы данных требуют разной скорости доступа, технологий обработки, компрессии и так далее. К примеру, виртуальный СХД для работы с большими медиа-файлами отличается от той системы, которая будет работать с неструктурированными данными для нейросети.
Объём данных
От этого зависит выбор дисковых накопителей. Иногда можно обойтись SSD потребительского класса — если известно, что ёмкость СХД даже в худшем случае не будет превышать 300 ГБ, а скорость доступа не критична.
Отказоустойчивость
Необходимо представлять, какова стоимость потери данных за определённое время. Это поможет рассчитать RPO (Recovery-Point Objective) и RTO (Recovery Time Objective), а также избежать лишних затрат на резервное копирование. Бэкапы, бэкапы и ещё раз бэкапы.
Производительность
Если СХД закупается под новый проект (нагрузку которого сложно предугадать), то лучше пообщаться с коллегами, которые уже решали эту задачу или протестировать СХД.
Вендор
Иногда даже для ресурсоемкого сервиса подойдет бюджетное или среднеуровневое решение (StarWind, Huawei, Fujitsu). Однако у топовых производителей — NetApp, HPE, Dell EMC — линейка продуктов достаточно широкая, и сравнительно недорогие СХД здесь также можно найти. В любом случае, желательно сильно не расширять количество вендоров на одной инфраструктуре.
⌘⌘⌘
Если сейчас вы находитесь в поисках решения для работы с данными, арендовать выделенный web-сервер и СХД (системы хранения данных) можно в одном из наших ЦОД. Мы, со своей стороны, обеспечим сервер быстрым соединением с интернетом на скорости до 10 Гбит/сек, постоянным подключением к электричеству и поддержкой 27/7 ;).
Арендовать выделенный сервер
NAS (Network Attached Storage)
Представим себе сервер в локальной сети, который не делает ничего, кроме как расшаривает свои папки. Это практически и есть NAS. Да, NAS – это всего лишь устройство для файлового обмена в IP сети. Минимальная конфигурация NAS выглядит так:
Введение в системы хранения данных-03
О структуре. NAS-устройство (файл-сервер) – это выделенный высокопроизводительный сервер, имеющий собственную ОС, оптимизированную для операций чтения/записи. Сервер имеет несколько сетевых интерфейсов для связи с IP сетью и устройством хранения: GigabitEthernet, FastEthernet, FDDI и проч. Кроме того, NAS обладает большим объемом оперативной памяти, большая часть которой используется как кеш, что позволяет выполнять операцию записи асинхронно, а чтение ускорить за счет буферизации. Таким образом, данные могут долгое время находится в оперативной памяти, не попадая на диск. NAS позволяет централизованно хранить данные и предоставляет удаленный доступ к ним всем авторизованным пользователям, независимо от типа клиентского устройства.
Storage (дисковый массив) – то, что чаще всего изображается в статьях, где речь идет о дата-центрах. Другими словами это шкаф (стойка) с дисками, соединенный (или интегрированный) с файл-сервером. Интегрированный? Да, NAS может быть отдельным сервером (как на рисунке) или входить в состав цельного устройства. В первом случае имеем дело с gateway реализацией NAS, во втором – с монолитной системой. О gateway реализации мы еще вспомним, когда будем говорить о SAN.
Назначение NAS — дать пользователям возможность более эффективно сотрудничать и обмениваться данными, особенно в рабочих группах, которые находятся удаленно или в разных часовых поясах. NAS подключается к беспроводному маршрутизатору, что упрощает для распределенных рабочих сред доступ к файлам и папкам с любого устройства, подключенного к сети
Как работает NAS? NAS поддерживает работу с протоколами шаринга CIFS и NFS. Клиент монтирует у себя файловую систему, предоставляемую NAS’ом и выполняет операции чтения/записи в обычном файловом режиме, а сервер NAS их обрабатывает, переводя на язык блочного доступа, понятный стораджу. Кроме этого, поддерживаются такие протоколы, как FTP, DFS, SMB.
NAS — это своего рода частное облако для офисного использования.
Системы NAS популярны среди предприятий и малых предприятий во многих отраслях как эффективные, масштабируемые и недорогие решения для хранения данных. Их можно использовать для поддержки систем электронной почты, бухгалтерских баз данных, расчета заработной платы, записи и редактирования видео, регистрации данных, бизнес-аналитики и многого другого; NAS-системы поддерживают множество других бизнес-приложений.
Учитывая гибкость и популярность систем NAS, большинство поставщиков облачных услуг предлагают услуги NAS; Это позволяет смешивать и сочетать системы хранения NAS и облачные сервисы в бизнесе, позволяя оптимизировать затраты, усилия по управлению и производительность, давая бизнесу полный контроль над местоположением и безопасностью.
Какой профит от использования NAS и почему типовому решению нужно отводить целый класс?
- Во-первых, операции IO занимают меньше времени, следовательно, NAS работает существенно быстрее, чем сервера «общего назначения», так если в вашей архитектуре есть сервер, который должен отдавать много статики, стоит подумать об использовании NAS.
- Во-вторых, централизованное хранение проще в управлении.
- В-третьих, общее увеличение емкости NAS происходит прозрачно для клиентов, все операции добавления/удаления памяти скрыты от потребителей.
- В-четвертых, предоставление доступа на уровне файловой системы позволяет вводить понятие привилегий rwx. Забегая вперед, можно отметить, что при помощи NAS без ущерба пропускной способности легко организовать мультисайтововсть (о том, что это такое мы расскажем, когда речь пойдет о репликации).
- Системы NAS отличаются высокой гибкостью и масштабируемостью, позволяя устанавливать новые накопители в дополнение к уже имеющимся
Но есть и ряд ограничений, связанных с использованием NAS. В основном это связано с базовым для NAS принципом. Сама по себе избыточность TCP/IP как протокола доступа к данным приводит к накладным расходам. Высокая нагрузка на сеть с довольно ограниченной пропускной способностью увеличивает время отклика. Производительность системы в целом зависит не только от NAS, но и от качества работы коммутирующих устройств сети. Кроме того, без правильного resource allocation, клиент, запрашивающий слишком большие объемы файлов, может влиять на скорость работы других клиентов
Состав и структура ЦОД
Основными элементами ЦОДа являются системы обработки и хранения данных, активное сетевое оборудование, инженерные системы. В нем размещаются вычислительные платформы и СХД, система передачи данных, система электроснабжения и электроосвещения, система прецизионного кондиционирования, структурированная кабельная система, система кабельных каналов, фальшпол, подвесной потолок, интегрированная система безопасности, средства физической защита вычислительных систем и телекоммуникационного оборудования, системы раннего обнаружения пожара и газового пожаротушения.
Структура ЦОД.
Сетевая инфраструктура (СКС) обеспечивает взаимодействие между серверами, а также включает в себя магистральные каналы для связи с операторами и коммуникации для связи пользователей с ЦОДом.
Как работает хранилище iSCSI?
Чтобы лучше понять, как работает iSCSI, в первую очередь следует изучить некоторые жизненно важные компоненты iSCSI, такие как инициатор iSCSI и цель iSCSI. Инициатор iSCSI — это часть программного или аппаратного обеспечения, установленная на сервере для отправки запросов и получения ответов от цели iSCSI. Цель iSCSI находится на устройствах хранения, обеспечивающих хранилище, которое прослушивает команды инициаторов iSCSI и отвечает на них.
Как показано ниже, хранилище iSCSI работает путем передачи данных на уровне блоков между инициатором iSCSI на сервере и целью iSCSI на устройстве хранения через сеть TCP/IP. Протокол iSCSI инкапсулирует команды SCSI и собирает данные в пакеты для уровня TCP/IP. Пакеты отправляются по сети с использованием двухточечного соединения. По прибытии протокол iSCSI разбирает пакеты, разделяя команды SCSI, поэтому операционная система будет видеть хранилище, как если бы это было локально подключенное устройство SCSI, которое можно отформатировать как обычно.
Что
Вендор
- Высший дивизион — заслуженные компании с широкой линейкой от самых простых дисковых полок до hi-end (HPE, DellEMC, Hitachi, NetApp, IBM / Lenovo)
- Второй дивизион — компании с ограниченной линейкой, нишевые игроки, серьезные вендоры SDS или поднимающиеся новички (Fujitsu, Datacore, Infinidat, Huawei, Pure и тд)
- Третий дивизион — нишевые решения в ранге low end, дешевый SDS, наколенные поделия на ceph и других открытых проектах (Infortrend, Starwind и тд)
- SOHO сегмент — малые и сверхмалые СХД уровня дом/малый офис (Synology, QNAP и тд)
- Импортозамещенные СХД — сюда входят как железо первого дивизиона с переклеенными лейблами, так и редкие представители второго (RAIDIX, дадим им авансом второй), но в основном это третий дивизион (Aerodisk, Baum, Depo и тд)
Гибридные / All Flash Array
- AFA (All Flash Array) — системы, оптимизированные для использования SSD.
- Гибридные — позволяющие использовать как HDD, так и SSD или их сочетание.
Фирменные технологии
Flash cache
- Read Only. В этом случае кэшируются только данные на чтение, а запись проходит сразу на диски. Некоторые производители, как например, NetApp, считают что запись на их СХД проходит и так оптимальным образом, и кэш никак не поможет.
- Read/Write. Кэшируется не только чтение, но и запись, что позволяет буферизовать поток и снизить влияние RAID Penalty, а как следствие повысить общую производительность для СХД с не таким оптимальным механизмом записи.
Snapshot
CoW (Copy-On-Write)RoW (Redirect-on-Write)Application consitentCrash consistent
- Безагентное резервное копирование напрямую с СХД
- Создание тестовых сред на основе реальных данных
- В случае с файловыми СХД может использоваться для создания сред VDI через использование снапшотов СХД вместо гипервизора
- Обеспечение низких RPO путем создания снапшотов по расписанию с частотой значительно выше частоты резервного копирования
Metro cluster
- Полная автоматизация процесса восстановления после смерти одного из датацентров. Без каких либо дополнительных средств все ВМ, работавшие в умершем датацентре, будут автоматически перезапущены в оставшемся. RTO = таймаут кластера высокой доступности (15 секунд для VMware) + время загрузки операционной системы и старта сервисов.
- Disaster avoidance или, по-русски, избежание катастроф. Если запланированы работы по электропитанию в датацентре 1, то мы заранее, до начала работ, имеем возможность мигрировать всю важную нагрузку в датацентр 2 нон стоп.
Виртуализация
- Резервирование на уровне СХД. Создается зеркало между томами, причем одна половина может быть на HP 3Par, а другая на NetApp. А виртуализатор от EMC.
- Переезд данных с минимальным простоем между СХД разных производителей. Предположим, что данные надо мигрировать со старого 3Par, который пойдет под списание, на новый Dell. В этом случае потребители отключаются от 3Par, тома прокидываются под VPLEX и уже презентуются потребителям заново. Поскольку ни бита на томе не изменилось, работа продолжается. Фоном запускается процесс зеркалирования тома на новый Dell, а по завершению зеркало разбивается и 3Par отключается.
- Организация метрокластеров.
InlinePost
iSCSI vs Fibre Channel
Fibre Channel (FC) и iSCSI — две ключевые технологии, связанные с SAN, и эти две технологии решают одну и ту же техническую проблему сетевого блочного хранилища, хотя их позиционируют как жестких конкурентов. Люди часто спрашивают Fibre Channel SAN или iSCSI SAN: что лучше для SAN? Это сравнение Fibre Channel и iSCSI поможет вам принять решение:
Особенности | FC | iSCSI |
---|---|---|
Позволяет использовать в существующей сети | Нет | Да |
Доступ на уровне блоков | Да | Да |
Надежное управление потоком данных (проверка CRC, предотвращение повторных попыток передачи) | Да | Нет |
Встроенная сервисная инфраструктура | Да | Нет |
Сетевая изоляция по дизайну | Да | Нет |
Необходимо покупать специальное оборудование (адаптеры, коммутаторы и т. д.) | Да | Да/Нет (хорошая производительность невозможна без специальных адаптеров) |
Доступные скорости передачи | 2/4/8/16/32 Гбит/с, поддержка агрегации каналов | 1/10/40/100 Гбит/с, поддержка агрегации каналов |