Pull to refresh
24
Karma
0
Rating
Дмитрий @bbk

Пользователь

Как выбрать СХД, не выстрелив себе в ногу

Система Хранения Данных

Как выбрать СХД, не выстрелив себе в ногу

Именно из-за таких вот комментариев я и перестал писать свои статьи на хабре.
А вот попробуйте сами что-то написать. Прийдут такие же как вы и спасибо не скажут.

Как выбрать СХД, не выстрелив себе в ногу

Мелким компаниям из 15 сотрудников, может и нужно, но здесь вопрос не в том что хотелось бы, а в том что у таких компаний денег на это нет. По этому такие комапнии выкручиваются самосбором а-ля Windows File Server или Linux NFS. И такой подход приемлем и скорее всего даже бизес-обоснован для таких компаний.
Но не нужно пытаться натянуть мартышку на глобус, для больших компаний этот же подход просто не катит.
А вот огромные клауд-провайдеры а-ля AWS/Azure/Google/Alibaba/IBM могут себе позволить это держать на самосборе. Но даже они не могут покрыть все портебности бизнеса в системах хранения, собственно по этому вендоры появляются как услуга в этих гигантах со своими железяками и софтом. Потому что десятки лет опыта, интеграцию и экосистему, не пропьёшь.

NetApp Insight 2018

В 2019 году Insight пройдёт только в Las Vegas.
А в 2020 Insight будет в Tokyo, Sydney, UK, Germany, France и по идее, как обычно, в Las Vegas.

VyOS OpenSource Router

Собственно VyOS он как раз для сетевых инженеров.

VyOS OpenSource Router

На сколько я знаю, то это можно сделать, но я не пробовал.
Спросите лучше на форуме или в слаке.

VyOS OpenSource Router

Это Open Source проект, любые киллер фичи добавляют энтузиасты. Точно также и с идеями, если есть хорошая идея её проект принимает и реализует.

Свои идеи и запросы по фичам можно размещать на этом сайте phabricator.vyos.net в разделе «Submit Feature Request».

VyOS OpenSource Router

Есть Ubiquiti EdgeRouter железо которое юзает VyOS.
Почему Проект вдруг должен из-за этого закончиться, не понятно.

Что умеет СХД — или старые песни о главном

Срого говоря да, вы правы, это не только файловая система. Но на фоне всего функционала, что есть у NetApp ONTAP, сама по себе ZFS на линуксе имеет жалкий функционал. Потому-то я и использовал фразу «это только файловая система».

Ближайшее будущее NetApp

Собственно KorP работает в сервис провайдере которые юзают SF. Спросите его о том довольны ли они и какие есть нюансы. Он кстати статью на хабре про SF выкладывал, можете взглянуть если интересно.

Ближайшее будущее NetApp

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

Ближайшее будущее NetApp

Там есть требования по минимальному количеству дисков которые нужно добавлять в систему нужно делать «правильное», в смысле проприетарное кабелирование дисковых полок которое у каждого производителя своё уникальное, правильно диски докидывать. Это всё ведёт к тому, что необходимо более-мение глубокое понимание внутренней архитектуры СХД, которая не то что у каждого производителя разная, у каждой линейки разная.

В то время как SF нода подключается по Ethernet архитектурно так сделано, чтобы потребители СХД, как оно там устроено внизу, знать не то что не должны, им просто по барабану. А Ethernet он и в Африке Ethernet. Два кабеля в свичи воткнул и поехали. Не думаем о RAID, дисковых полках, специальных коммутациях, чтением мануалов, и вообще внутренней архитектуре СХД. Такую СХД как SF или HCI могут «потреблять» люди без специальных знаний СХД, к примеру отдел виртуализации или программисты из Dev/Ops. Разница по сути в существенном упрощении с точки зрения потребления пространства и производительности.

3Par и тот же NetApp FAS конечно же очень интерестные и стоящие системы под свои задачи. SF/NetApp HCI нужен если же задача построить инфраструктуру для сервис-провайдера, или исключительно виртуальной инфраструктуры VMware или инфраструктуру для Dev/Ops, которые не хотят ждать, а просто запросить по RESTFul API и получить гарантированную производительность и заданное пространство, вот прям сходу, сразу, ничего не тюнингуя, как только систему воткнути в питание и в свичи, ничего толком не конфигурируя кроме нескольких IP адресов.

Ближайшее будущее NetApp

кстати если мы говорим про Vmware, то там можно использовать vVOl, с которыми можно отдельно на ВМ (точнее на виртуальный диск от ВМ) настраивать QoS по IOPS.

Ближайшее будущее NetApp

:)) латенси в QoS засунуть архитектурно и технически не возможно, чтобы гарантировать постоянно минимальное значение латенси, разве что сделать «уровни» а-ля плохо-хорошо-отлично. QoS по-сути делает прерывания (паузы) на те потоки чтения/записи, которые относятся к тому или иному луну, в зависимости от их настроек. Другими словами чтобы герентировать латенси одному луну, нужно чтобы другие страдали, другими словами это не натягивается на идею общего хранилища ни на идею HCI. Чтобы латенси всегда была минимальная, необходимо иметь выделенные диски.
В SF/HCI NetApp говорит что будет sub-millisecond latency.

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

Ближайшее будущее NetApp

В SF QoS в виде IOPS настраивается на лун, на VM нельзя. QoS в SF работает очень интерестно: каждому луну отдельно QoS натраивается минимальное, максимальное и пиковое значения IOPS. Любой лун не может получить меньше чем задано значение Min, если луну в этот момент не нужно максимум, то он получает минимум, а разница начисляется на будущее в виде кредитов. Когда же приложение «просыпается» и наченает потреблять свой максимум, система ему выдаёт «заработанные кредиты», пока они не будут выработаны. После того как кредиты выработаны производительность возвращается на максимум. Это очень удобно для сервис провайдеров.

Важно отметить что IOPS, IOPSу рознь. К примеру если вы настроите на SF 1000 минимум IOPS и при этом размер IOPS будет 4KB, значит у вас будет 4000 KB/s минимум. Если приложенеи будет генерировать блоки размером в 128KB, значит при тех же самых 1000 IOPS у вас будет уже 128000 KB/s минимум. Обычно приложения генерируют микс из разных размеров блоков, по этому иногда легче запустить приложение посмотреть сколько оно генерирует IOPS а потом установить минимум, максимум и пиковые значения.



На латенси QoS технически поставить не возможно. И я говорю о настоящем QoS а не о «уровнях» типа Gold/Silver etc.

По поводу 4): стоит подумать на счёт того чтобы в агрименте для пользователя прописать то что цена на ёмкость уменьшеется если данные сжимаются, и увеличивается, если данные несжимаемы (уже закомпресированные, зашифрованные или медиа файлы не сжимаются).

Ближайшее будущее NetApp

3Par, как к примеру и NetApp FAS не HCI (по крайней мере пока), потому что в обоих есть дисковые полки которые нужно уметь правильно подключать, что бы без останова, правильно диски раскидывать, разбивать и в рейды собирать, под приложения тюнить. И что важно специальные докуменнты на достаточно хорошем уровне изучать, чтобы мочь эти системы конфигурировать и эксплуатировать. Так что перед тем как vVOL можно с них забрать, нужно сначала это всё нафонфирурировать и так чтобы правильно.

В то время как NetApp Solid Fier это система которая состоит из нод, каждая из которых это и контроллер и дисковая полки, каждая нода это всего-лишь 10-12 SSD дисков, а кластер максимум из 100 нод. Соостественно она существенно гранулярнее традиционных СХД: можно добавлять и забирать ноды из кластера. Подключение это два кабеля питания и два кабеля для данных 10/25 Гбс. Ничего особо конфигурировать не нужно: задискаверил ноду в визарде и добавил в кластер. Автоматически общий пул пространства и перфоменса в кластере вырос.

К примеру у вас кластер из 8 нод. И у вас утилизация 60% пространства. 60% от 8 =4.8 нод (округляем до 5). 8-5=3 ноды можно забрать из кластера. Дальше из этих высвобожденных 3 нод нод можно создать второнй, новый кластер, если ещё добавить 1 ноду. В реальной продуктивной системе, с высоким уровнем записей, вы наверное всё-таки одну ноду стоит оставить, то есть забрать 2, а не 3, чтобы пространства не совсем так мало оставалось, но суть в том, что добавлять/удалять можно с гранулярностью в одну ноду.

Ближайшее будущее NetApp

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

Кабели, NIC/HBA в серверах и свичи, как ни крути всё-равно будут и у True HCI они никуда не делись. Единственное что нужно будет в 3 раза больше этих вот NIC, в 3 раза больше портов на свиче, где будет гоняться в 2 раза больше сетевого трафика и тех же самых кабелей в 3 раза больше.

Ситуацию немного может улучшить фактор репликации 2, тогда вам всего нужно в 2 раза больше, а не в 3 (Мама мия!). Но при этом немного ухудшить защищённость данных.

Касательно скорости, то «Записи не подтверждаются до тех пор, пока по сети удалённые ноды не подтвердят получения этих данных, что равносильно скорости работы с shared storage по сети».

Есть еще вариант сделать EC, и существенно сократить накладные расходы на железо и пространство, став по эффективности почти таким как shared storage, порядка 35%. Но при этом просев в производительности, потому что EC это по-сути сетевой RAID.

Ближайшее будущее NetApp

Основная цена HCI в простоте. А как оно реализовано, через софт или через железные коробочки, какая разница, всё-равно в итоге у вас эти железные коробочки в ЦОДе, что так что так.

Ближайшее будущее NetApp

Тоже вариант

Information

Rating
Does not participate
Location
Киев, Киевская обл., Украина
Registered
Activity