Именно из-за таких вот комментариев я и перестал писать свои статьи на хабре.
А вот попробуйте сами что-то написать. Прийдут такие же как вы и спасибо не скажут.
Мелким компаниям из 15 сотрудников, может и нужно, но здесь вопрос не в том что хотелось бы, а в том что у таких компаний денег на это нет. По этому такие комапнии выкручиваются самосбором а-ля Windows File Server или Linux NFS. И такой подход приемлем и скорее всего даже бизес-обоснован для таких компаний.
Но не нужно пытаться натянуть мартышку на глобус, для больших компаний этот же подход просто не катит.
А вот огромные клауд-провайдеры а-ля AWS/Azure/Google/Alibaba/IBM могут себе позволить это держать на самосборе. Но даже они не могут покрыть все портебности бизнеса в системах хранения, собственно по этому вендоры появляются как услуга в этих гигантах со своими железяками и софтом. Потому что десятки лет опыта, интеграцию и экосистему, не пропьёшь.
Срого говоря да, вы правы, это не только файловая система. Но на фоне всего функционала, что есть у NetApp ONTAP, сама по себе ZFS на линуксе имеет жалкий функционал. Потому-то я и использовал фразу «это только файловая система».
Собственно KorP работает в сервис провайдере которые юзают SF. Спросите его о том довольны ли они и какие есть нюансы. Он кстати статью на хабре про SF выкладывал, можете взглянуть если интересно.
Ну вот поинтересуйтусь как устроена архитектура SF. Вы даже увидите что документация на много меньше чем тот же ONTAP, потому что оно простое в использовании как двери.
Единственная рекомендация по SF не делать один большой лун, а делать много лунов, что вполне подходит для любого сервис провайдера. Rackspace на SF работает.
Там есть требования по минимальному количеству дисков которые нужно добавлять в систему нужно делать «правильное», в смысле проприетарное кабелирование дисковых полок которое у каждого производителя своё уникальное, правильно диски докидывать. Это всё ведёт к тому, что необходимо более-мение глубокое понимание внутренней архитектуры СХД, которая не то что у каждого производителя разная, у каждой линейки разная.
В то время как SF нода подключается по Ethernet архитектурно так сделано, чтобы потребители СХД, как оно там устроено внизу, знать не то что не должны, им просто по барабану. А Ethernet он и в Африке Ethernet. Два кабеля в свичи воткнул и поехали. Не думаем о RAID, дисковых полках, специальных коммутациях, чтением мануалов, и вообще внутренней архитектуре СХД. Такую СХД как SF или HCI могут «потреблять» люди без специальных знаний СХД, к примеру отдел виртуализации или программисты из Dev/Ops. Разница по сути в существенном упрощении с точки зрения потребления пространства и производительности.
3Par и тот же NetApp FAS конечно же очень интерестные и стоящие системы под свои задачи. SF/NetApp HCI нужен если же задача построить инфраструктуру для сервис-провайдера, или исключительно виртуальной инфраструктуры VMware или инфраструктуру для Dev/Ops, которые не хотят ждать, а просто запросить по RESTFul API и получить гарантированную производительность и заданное пространство, вот прям сходу, сразу, ничего не тюнингуя, как только систему воткнути в питание и в свичи, ничего толком не конфигурируя кроме нескольких IP адресов.
кстати если мы говорим про Vmware, то там можно использовать vVOl, с которыми можно отдельно на ВМ (точнее на виртуальный диск от ВМ) настраивать QoS по IOPS.
:)) латенси в QoS засунуть архитектурно и технически не возможно, чтобы гарантировать постоянно минимальное значение латенси, разве что сделать «уровни» а-ля плохо-хорошо-отлично. QoS по-сути делает прерывания (паузы) на те потоки чтения/записи, которые относятся к тому или иному луну, в зависимости от их настроек. Другими словами чтобы герентировать латенси одному луну, нужно чтобы другие страдали, другими словами это не натягивается на идею общего хранилища ни на идею HCI. Чтобы латенси всегда была минимальная, необходимо иметь выделенные диски.
В SF/HCI NetApp говорит что будет sub-millisecond latency.
4) ну тогда продавайте без учёта дедупа. Потому что дедуп, у всех производителей, не может жать мультимедиа и уже скомпрессированные или зашифрованные данные.
В 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): стоит подумать на счёт того чтобы в агрименте для пользователя прописать то что цена на ёмкость уменьшеется если данные сжимаются, и увеличивается, если данные несжимаемы (уже закомпресированные, зашифрованные или медиа файлы не сжимаются).
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, чтобы пространства не совсем так мало оставалось, но суть в том, что добавлять/удалять можно с гранулярностью в одну ноду.
Ну так давайте посчитаем.
Если всё делаем с фактором репликации 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.
Основная цена HCI в простоте. А как оно реализовано, через софт или через железные коробочки, какая разница, всё-равно в итоге у вас эти железные коробочки в ЦОДе, что так что так.
D-Wave One выпустил в 2020 квантовый компьютер с 5640 кубитами.
https://en.wikipedia.org/wiki/D-Wave_Systems
А вот попробуйте сами что-то написать. Прийдут такие же как вы и спасибо не скажут.
Но не нужно пытаться натянуть мартышку на глобус, для больших компаний этот же подход просто не катит.
А вот огромные клауд-провайдеры а-ля AWS/Azure/Google/Alibaba/IBM могут себе позволить это держать на самосборе. Но даже они не могут покрыть все портебности бизнеса в системах хранения, собственно по этому вендоры появляются как услуга в этих гигантах со своими железяками и софтом. Потому что десятки лет опыта, интеграцию и экосистему, не пропьёшь.
А в 2020 Insight будет в Tokyo, Sydney, UK, Germany, France и по идее, как обычно, в Las Vegas.
Спросите лучше на форуме или в слаке.
Свои идеи и запросы по фичам можно размещать на этом сайте phabricator.vyos.net в разделе «Submit Feature Request».
Почему Проект вдруг должен из-за этого закончиться, не понятно.
Единственная рекомендация по SF не делать один большой лун, а делать много лунов, что вполне подходит для любого сервис провайдера. Rackspace на SF работает.
В то время как SF нода подключается по Ethernet архитектурно так сделано, чтобы потребители СХД, как оно там устроено внизу, знать не то что не должны, им просто по барабану. А Ethernet он и в Африке Ethernet. Два кабеля в свичи воткнул и поехали. Не думаем о RAID, дисковых полках, специальных коммутациях, чтением мануалов, и вообще внутренней архитектуре СХД. Такую СХД как SF или HCI могут «потреблять» люди без специальных знаний СХД, к примеру отдел виртуализации или программисты из Dev/Ops. Разница по сути в существенном упрощении с точки зрения потребления пространства и производительности.
3Par и тот же NetApp FAS конечно же очень интерестные и стоящие системы под свои задачи. SF/NetApp HCI нужен если же задача построить инфраструктуру для сервис-провайдера, или исключительно виртуальной инфраструктуры VMware или инфраструктуру для Dev/Ops, которые не хотят ждать, а просто запросить по RESTFul API и получить гарантированную производительность и заданное пространство, вот прям сходу, сразу, ничего не тюнингуя, как только систему воткнути в питание и в свичи, ничего толком не конфигурируя кроме нескольких IP адресов.
В SF/HCI NetApp говорит что будет sub-millisecond latency.
4) ну тогда продавайте без учёта дедупа. Потому что дедуп, у всех производителей, не может жать мультимедиа и уже скомпрессированные или зашифрованные данные.
Важно отметить что IOPS, IOPSу рознь. К примеру если вы настроите на SF 1000 минимум IOPS и при этом размер IOPS будет 4KB, значит у вас будет 4000 KB/s минимум. Если приложенеи будет генерировать блоки размером в 128KB, значит при тех же самых 1000 IOPS у вас будет уже 128000 KB/s минимум. Обычно приложения генерируют микс из разных размеров блоков, по этому иногда легче запустить приложение посмотреть сколько оно генерирует IOPS а потом установить минимум, максимум и пиковые значения.
На латенси QoS технически поставить не возможно. И я говорю о настоящем QoS а не о «уровнях» типа Gold/Silver etc.
По поводу 4): стоит подумать на счёт того чтобы в агрименте для пользователя прописать то что цена на ёмкость уменьшеется если данные сжимаются, и увеличивается, если данные несжимаемы (уже закомпресированные, зашифрованные или медиа файлы не сжимаются).
В то время как NetApp Solid Fier это система которая состоит из нод, каждая из которых это и контроллер и дисковая полки, каждая нода это всего-лишь 10-12 SSD дисков, а кластер максимум из 100 нод. Соостественно она существенно гранулярнее традиционных СХД: можно добавлять и забирать ноды из кластера. Подключение это два кабеля питания и два кабеля для данных 10/25 Гбс. Ничего особо конфигурировать не нужно: задискаверил ноду в визарде и добавил в кластер. Автоматически общий пул пространства и перфоменса в кластере вырос.
К примеру у вас кластер из 8 нод. И у вас утилизация 60% пространства. 60% от 8 =4.8 нод (округляем до 5). 8-5=3 ноды можно забрать из кластера. Дальше из этих высвобожденных 3 нод нод можно создать второнй, новый кластер, если ещё добавить 1 ноду. В реальной продуктивной системе, с высоким уровнем записей, вы наверное всё-таки одну ноду стоит оставить, то есть забрать 2, а не 3, чтобы пространства не совсем так мало оставалось, но суть в том, что добавлять/удалять можно с гранулярностью в одну ноду.
Если всё делаем с фактором репликации 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.