CAP теорема и нутанихс
Nov. 10th, 2018 08:29 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
scif_yarКак доносят голоса, в одной запрещенной в РФ коммуночке (запрещена тележка, а не коммуночка), разразился срач, что Нетапп говно / неговно (коммуна не нетапп, так что говно). Раздавались крики Ш о CAP-теореме и всем этом.
Ну и о FHCI — Fake Hyper Convergent Infractucture
Это почти как fake taxi, только fake HCL.
Пришлось читать.
https://ru.wikipedia.org/wiki/Теорема_CAP
https://habr.com/post/130577/
Условный срач идет тут -
https://habr.com/post/429122/
начиная отсюда https://habr.com/post/429122/#comment_19338904
Условный - потому что там 70 комментов, в в теме про увольнения - срач недели https://habr.com/post/428840/ - 600+ комментов, вот так не горит.
Но срач про увольнения мне не интересен, веселей про задержки и стораджи. Ну и полезнее.
Тут у меня в комментах бывают вовнеи с пустыми ЖЖ и через американский прокси (или тор, не одна ли фигня), и сам Вовни лично, которые не понимают, что содрать с пакета адрес и запулить пакет далее - не одна процедура, а две, прием в буфер - выпихивание в буфер, и в любом случае занимает времени больше, потому что в цепочке "хост - SAN SW прием-передача - СХД" на одно звено меньше, чем в цепочке хост - FCoE forwarders (прием) - обработка - FC отдача.
Хотя вопрос "насколько дольше" он самый интересный, как и детальный разбор, что там где происходит. Именно в цифрах, потому что процедуры в штуках это одно, а задержки на них это другое. 5 процедур по 1 секунде все равно быстрее 2 процедур по 3 секунды.
Так вот, при раскладе 80/20 (чтение/запись), чтение с локального размазанного (а у нутанихс под капотом те же экстенты, просто в той паре книжек, которые я читал, про это как-то мимоходом) тома будет очевидно быстрее, чем с удаленного, а вот запись да, запись будет плюс-минус потолок "как у СХД" - потому что надо отдать измененные данные в реплики и дождаться ответа от реплик, а это все равно задержки (и опять же вопрос, а какие задержки? Сколько дают всякие быстрые свичи уровня Аристы, а сколько - обычные SAN, FCoE, и прочие iSCSI, если СХД презентована по iSCSI, NFS, или как-то еще, даже и SMB ?). Это все есть в цифрах и скучных таблицах, и выливается в скучные графики, но чтения все равно ОБЫЧНО больше и соответственно локально читается быстрее.
Правда, есть и цена вопроса. Чтобы быстро читать, надо или all-flash, или толстый read-cache, или сверху прикрученный тиринг, или все сразу и скопом, а это дорого. Плюс для одного сервера (ноды) мы упираемся в то, что слишком много данных на нее класть тоже еще вопрос, стоит ли - а если откажет, хватит ли мощности оставшихся, и в место - у нас объем данных **2 или **3, то есть три копии, но с другой стороны есть дедупликация и сжатие (ну так оно и на массивах есть).
Общем, все упирается в вопросы "а чего хотим-то, почем и как". Пока что нет закона РФ о том, что нельзя и так и эдак и еще вон тот сторадж притащить и прикрутить.
Так вот, про срач, хотя какой там сраз, 70 комментов.
Но можно напиздить ссылок и картинок
Хорошая статья например тут:
techcrunch.com/2016/05/22/why-google-beat-yahoo-in-the-war-for-the-internet
Erasure Coding-X (EC-X): Predictably Increase Usable Storage Capacity
https://www.nutanix.com/2015/06/17/erasure-coding-x-ec-x-predictably-increase-usable-storage-capacity/
И еще можно напиздить умных слов типа mapreduce
Ну и о FHCI — Fake Hyper Convergent Infractucture
Это почти как fake taxi, только fake HCL.
Пришлось читать.
https://ru.wikipedia.org/wiki/Теорема_CAP
https://habr.com/post/130577/
Условный срач идет тут -
https://habr.com/post/429122/
начиная отсюда https://habr.com/post/429122/#comment_19338904
Условный - потому что там 70 комментов, в в теме про увольнения - срач недели https://habr.com/post/428840/ - 600+ комментов, вот так не горит.
Но срач про увольнения мне не интересен, веселей про задержки и стораджи. Ну и полезнее.
Тут у меня в комментах бывают вовнеи с пустыми ЖЖ и через американский прокси (или тор, не одна ли фигня), и сам Вовни лично, которые не понимают, что содрать с пакета адрес и запулить пакет далее - не одна процедура, а две, прием в буфер - выпихивание в буфер, и в любом случае занимает времени больше, потому что в цепочке "хост - SAN SW прием-передача - СХД" на одно звено меньше, чем в цепочке хост - FCoE forwarders (прием) - обработка - FC отдача.
Хотя вопрос "насколько дольше" он самый интересный, как и детальный разбор, что там где происходит. Именно в цифрах, потому что процедуры в штуках это одно, а задержки на них это другое. 5 процедур по 1 секунде все равно быстрее 2 процедур по 3 секунды.
Так вот, при раскладе 80/20 (чтение/запись), чтение с локального размазанного (а у нутанихс под капотом те же экстенты, просто в той паре книжек, которые я читал, про это как-то мимоходом) тома будет очевидно быстрее, чем с удаленного, а вот запись да, запись будет плюс-минус потолок "как у СХД" - потому что надо отдать измененные данные в реплики и дождаться ответа от реплик, а это все равно задержки (и опять же вопрос, а какие задержки? Сколько дают всякие быстрые свичи уровня Аристы, а сколько - обычные SAN, FCoE, и прочие iSCSI, если СХД презентована по iSCSI, NFS, или как-то еще, даже и SMB ?). Это все есть в цифрах и скучных таблицах, и выливается в скучные графики, но чтения все равно ОБЫЧНО больше и соответственно локально читается быстрее.
Правда, есть и цена вопроса. Чтобы быстро читать, надо или all-flash, или толстый read-cache, или сверху прикрученный тиринг, или все сразу и скопом, а это дорого. Плюс для одного сервера (ноды) мы упираемся в то, что слишком много данных на нее класть тоже еще вопрос, стоит ли - а если откажет, хватит ли мощности оставшихся, и в место - у нас объем данных **2 или **3, то есть три копии, но с другой стороны есть дедупликация и сжатие (ну так оно и на массивах есть).
Общем, все упирается в вопросы "а чего хотим-то, почем и как". Пока что нет закона РФ о том, что нельзя и так и эдак и еще вон тот сторадж притащить и прикрутить.
Так вот, про срач, хотя какой там сраз, 70 комментов.
Но можно напиздить ссылок и картинок
Хорошая статья например тут:
techcrunch.com/2016/05/22/why-google-beat-yahoo-in-the-war-for-the-internet
Erasure Coding-X (EC-X): Predictably Increase Usable Storage Capacity
https://www.nutanix.com/2015/06/17/erasure-coding-x-ec-x-predictably-increase-usable-storage-capacity/
И еще можно напиздить умных слов типа mapreduce
no subject
Date: 2018-11-10 11:41 am (UTC)no subject
Date: 2018-11-10 01:32 pm (UTC)1. Задержки сети - это фигня. Задержка магнитного HD - это миллисекунды, задержка SSD - это сотни мкс. Задержки сети, ну, вот Arista размахивает сотнями нс, но даже если это единицы мкс - ну и что, это все равно жалкая доля общей латентности.
2. Локальность чтения, которой размахивает Нутаникс, по этой же причине не столь критична, ибо задержки сети на порядок-другой ниже задержек хранилки.
3. Офигенность Нутаникса обеспечивалась тирингом и реально толстым SSD-кэшем. Фактически он был настолько толст, чтобы все горячие данные (окей, 90%) в него попадали.
4. Сейчас с уверенным шаганием all-flash по планете в силу п.1 для среднестатистических задач любого HCI (vSAN, Nutanix) хватает с головой.
5. Крутость HCI в том, что за счет сборки на обычном железе (ИЧСХ под капотом хранилок часто оно же) вдруг оказывается, что бОльшее число дешевых SSD дешевле меньшего числа более дорогих, которые пихаются в классическую хранилку, а, что еще более важно, пицот дешевых серверных контроллеров, каждый из которых задохнется на 10 килоиопс, дешевле пары СХДшных, которые должны давать по 100 килоиопс и не гундеть. И так далее.
6. А что до CAP-теоремы... ну, если у вас масштабный partitioning на вашей задублированной (а шо, нет?) выделенной (10G-порты ныне недороги) сети, то у вас тащемта чуть бОльшие проблемы, чем CAP-теорема - и, кстати, в классической архитектуре та партиция, в которой не оказалось хранилки, тоже встает колом. А в намного более частом прикладном случае, когда один хост встал колом, практика показывает, что то время, за которое остальные успевают сказать: "Помер Максим, да и шут с ним" вполне приемлемо для всего, что работает поверх этого бардака. Примерно как заморозка в процессе vMotion/svMotion.
7. Аргумент NetApp про то, что вы, мол, уменьшая вычислялку, уменьшаете диски, и это плохо - он лажовый. Ну окей, для SMB это может быть неудобно. Как только вы хотя бы сунули ногу в дверь с табличкой "энтерпрайз", у вас настолько много всякого хабара, что ваше соотношение процессор-память-диск если и колеблется, то еле-еле, а потому рост одного влечет за собой рост другого, и тут как раз HCI очень в тему.
Кто людям помогает - тот тратит время зря.
Date: 2018-11-10 04:15 pm (UTC)По делу - 1, 2 и 4 - так и есть.
#3 - hybrid arrays кто только не делал, не Nutanix единым. Изначально Nutanix решал две проблемы - VDI boot storm и ROBO. В данный момент VDI прекрасно летает на all-flash. ROBO продолжает быть правильным местом для запихивания HCI (только не от NetApp :-))
#5 - не совсем так. Если не играть в любимую игру Nutanix "купите с поддержкой на первый год, а потом мы вам вдуем", обычные converged stack вполне себе конкурируют.
#7 - Не только NetApp про это песни поёт. В HyperFlex compute only nodes тоже есть. И локальность данных отсутствует (это больше к #1). Аргумент вполне рабочий. Каким бы стабильным не было соотношение CPU/RAM/"HDD" - если в момент покупки не нужно об этом заботиться, всем обычно легче.
Ну и так, мимоходом - долина в процессе NVMe/NVMeF революции. SCSI наконец то одной ногой в могиле.
Re: Кто людям помогает - тот тратит время зря.
Date: 2018-11-10 04:18 pm (UTC)-
на этом месте мы пожалуй попрощаемся с очередным персонажем с пустым жж.
no subject
Date: 2018-11-10 04:34 pm (UTC)-
Сколько времени у тебя займет ребилд скажем 10-Тб vsan при необходимости замены SSD?
сеть ну пусть 25Gb, система с включенным дедупом.
кроме того, vsan сцукотоподорого.
no subject
Date: 2018-11-10 06:14 pm (UTC)Да, VSAN стоит дорого, но, кстати, не сильно дороже (если не дешевле) этого вашего 3Par, если только у вас не 10-20 Тб, а этак 80+. А что, Нутаникс дешево? Или NetApp дешево, который не самый тупой файлер, а который с иопсами и все такое?
Не уловил сути коммента.
no subject
Date: 2018-11-10 06:47 pm (UTC)-
Я к тому, что во первых я тут по работе патч-хистори смотрел во варе - каждый патч что-то для vsan, и каждый раз ссыкотно.
а во вторых сколько будет ждать варя до начала ребилда и отдупления, а сколько нутаникс.
Надо мне уже будет написать псто, и самому для себя прояснить этот вопрос.
---
>>этого вашего 3Par, если только у вас не 10-20 Тб, а этак 80+. А что, Нутаникс дешево? Или NetApp дешево
-
да он что на 10 тб, что на больше - нифига не дешево. не фринас и не синолоджи и не старый добрый 1050-1052.
no subject
Date: 2018-11-10 04:18 pm (UTC)-
В таблице ниже приведены задержки для разных типов I/O:
NAND NVMe SSD R/W 20,000 ns
Задержка P2P TCP/IP (физика на физику) 150,000 ns
Поиск диска 10,000,000 ns или 10,000 us
а дальше надо читать доки и гуглить, чтопочем для SAN (сколько там - 800 ns port-to-port latency supports speedy data transmission with a minimum of dropped packets для VDX 6940) у циски и аристы.
>>1. Задержки сети - это фигня
-
да ? )) А предел в 100-150-200 км для всяких там "просто так реплик" он не из задержек по сети растет ? )))
no subject
Date: 2018-11-10 06:21 pm (UTC)Вот 800 ns я у Аристы видел; про NVMe я говорить не готов. 150 мкс задержки TCP/IP (а это в одну сторону или в две, а это ICMP, TCP или UDP?) кстати, не выглядят ужасно.
И давай не надо двигать ворота. Задержки сети внутри СХД датацентра (чистый L2, часто с одним хопом между приемником и источником) по сравнению с задержками типичного SSD реально фигня. А про реплики и сотни километров я не говорил - а в их случае у тебя первую скрипку играет физика и скорость света, которым совершенно срать на NetApp, Nutanix и прочее.
Не мешай в одну кучу тушенку и сгущенку: продукты хороши по отдельности, а вот вместе - редкостная гадость.
no subject
Date: 2018-11-10 07:02 pm (UTC)-
это цитата из библии нутаникс разных изданий, первого и третьего.
http://nutanix.ru/ и http://nutanixbible.ru/
---
>>10 мс на поиск по HD? То есть ты утверждаешь, что 2.5 мс из спецификаций - это брехня?
-
не брехня, а вопрос какая из ?
вот вики
Rotational speed
[rpm] Average rotational latency
[ms]
15,000 2
10,000 3
7,200 4.16
вот дисочек -
Seagate Enterprise Performance 10K Specifications
Average Latency (ms): 2.9
ну и там же для тестовых сценариев -
When looking at average latency, the Seagate 10k8 showed a massive improvement with reads at 23.33ms and writes at 35.91ms compared to the TurboBoost model, which had 63.66ms read and 34.52ms write.
https://www.storagereview.com/seagate_enterprise_performance_10k_hdd_review
---
>> 150 мкс задержки TCP/IP
-
туда-обратно.
Да, это не выглядит ужасно, но тут задержка, там задержка, все вместе это накапливается.
---
>>а в их случае у тебя первую скрипку играет физика и скорость света, которым совершенно срать на NetApp, Nutanix и прочее.
-
Я это в данном случае рассматриваю иначе, исходя по ТАУ. И то и другое и третье и еще 33-е - это все элемент с задержкой. То есть мне в общем случае пофиг, вносит ли задержку физика вида переключения транзисторов туда-сюда, или это физика распространения отраженной волны в проводнике. В любом случае это вносимая задержка, просто в одном элементе это 1, а в другом 101. В любом случае от того момента, когда я покричу в трубу "эгегей" - сумма задержки (от ответа ололо) выйдет 102 туда и 102 обратно (и еще там подумать). Всякое кеширование и тут и там и упреждающее чтение конечно меня спасет, но не всего и не всегда. И это пока мы говорим только про чтение.
no subject
Date: 2018-11-10 09:10 pm (UTC)"Поиск диска 10,000,000 ns" - никто тебя и их за язык не тянул. Но на это есть average seek time, которое как раз емнип 2.5 мс. Да, есть rotational latency, которая 60/rpm (иногда пополам).
Есть фактическая общая latency, и мне ли не знать, что она бывает и 10, и 31 и поболее мс. Но цитировал ты именно "поиск диска".
А что до задержек, я тебе про фому, а ты мне про ерему. Я утверждаю, что в контексте HCI, близком мне, то есть внутри датацентра, сетевые задержки все еще на порядок меньше дисковых (кто сказал NVMe?), а потому влияют мало.
А ты мне начинаешь говорить, что вот, когда у нас синхронная репликация на сотню километров, то сетевая задержка еще как роляет (ежу понятно), а при достижении определенной величины начинает создавать проблемы. Это совсем не про то.
На это я могу сказать, что 1) при синхронной дальней репликации на эти твои 150 км у тебя только скорость света сожрет миллисекунду, и именно это начинает ролять 2) Вот когда мне будет актуален VSAN Stretch Cluster или его аналог от кого угодно, вот тогда я буду это пристально изучать. А сейчас я знаю про сам факт, и мне того довольно.