Ух как все неэффективно оказывается работает)

Ух как все неэффективно оказывается работает)

Самое эффективное реплицированние данных в ceph

Записать одни и теже данные 5 раз

у абстрактного кластера абстрактные шарды. кластер конкретно не эффективен.

архитектор не очень.

архитектор не очень.

Как и все они

У 7 девопсов абстрактный кластер без шардов

Окей у лучшего кластера и только на запись - как будет?

с гарентией целостности данных ?

Да

с двухфазными коммитами ?

Да

какой кластер по CAP теореме ?

Нет

ни нет. а CA или AP ?

или без А вообще ?

CP, доступность как и раньше - не полная

http://digbigdata.com/wp-content/uploads/2013/05/media_httpfarm5static_mevIk.png

окей.

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

Всё, что вы не знали о CAP теореме / Хабр https://habr.com/ru/post/328792/

ну и отрежем мультк из схемы.

получается что весь пришедший трафик надо отреплицировать дальше. так что мы весь output будем использовать под отправку в шарды. получим при 100ке входа перегруз на выход.

кроме того надо надо будет писать нам надо будет еще и читать. при чтении возможно указать правила чтения

Как-то ты не так считаешь

правило чтения у нас могу быть majority/all/one

Я не говорил, что 100 входа. Я говорил, что полная ширина канала 100

Окей у лучшего кластера и только на запись - как будет?

Без чтения

вход делить на rf

служебным можно принебречь.

Rf+1, если точнее

нет.

in+out не скалдывай

А

Тогда это 1 мастер и несколько реплик

мы всё еще в понятиях абстрактного кластера ?

А в реальности сильно лучше?

у тя может быть ни одна точка входа.

Ну и если клиенты не знают, что на каком шарде лежит

хуже когда даже знают, но обратиться напрямую нельзя, у того же couchbase в кластере - запрос может быть перекинут на другую машину даже когда на этой есть нужные данные

у тя может быть ни одна точка входа.

Это можно, но надо зае**ться в коде реализовать

но с учетом гарантий С я признатся запутался

Посмотрите статью. Там об этом хорошо рассказано

посмотрю.

Ну, если мы говорим про условный Кубер, я не уверен, что там можно как-то адекватно расчитать необходимую ширину канала

О, Хоспади

но с учетом гарантий С я признатся запутался

Это все фигня, капа в природе нет (((

И вопрос правильной архитектуры - почему мы вообще говорим про 100мбит ? Это линк у провайдера ? Или на каждую ВМ ? Или где бекбон сеть ?

И вопрос правильной архитектуры - почему мы вообще говорим про 100мбит ? Это линк у провайдера ? Или на каждую ВМ ? Или где бекбон сеть ?

Да ширина полосы может быть любой. А вот процент служебных сообщений кластера - он плюс-минус постоянен

Да ширина полосы может быть любой. А вот процент служебных сообщений кластера - он плюс-минус постоянен

Не процент от полосы

А скорее от объема данных

Нет. Именно от полосы. Объём данных - он в базе записан и к сети отношения не имеет.

Нет

Не от полосы

Ну типа пример: 2 ПБ - это объём данных, который лежит в базе, поток данных, которым он до этого писался и будет писаться 50 мбпс. Это ширина полосы.

Ну типа пример: 2 ПБ - это объём данных, который лежит в базе, поток данных, которым он до этого писался и будет писаться 50 мбпс. Это ширина полосы.

Ну, окей, т.е. это переменная величина

Ну, можно, да

когда? как подписаться? я вот как раз сегодня случайно эти две репы читал...

А вот скорость физлинка - вполне конкретная и определена сверху

когда? как подписаться? я вот как раз сегодня случайно эти две репы читал...

Да придумаем, когда Пока не знаю, надо сообразить Сообразим

Теоретически 50мбпс входа могут многократно амплифицироваться в кластере

Ну это уже какие-то особые случаи

Кассандра работает иначе

Там изначально учли проблему перегруза каналов связи и ввели понятие Rack

Стойки с серверами

Но это не абстрактный кластер, а реализация кластера с учётом проблемы топологии

Стойки с серверами

Да, но я почти наверняка уверен, что кластерные решения рассчитаны на две сетевухи в ноде

И переливания данных между узлами кластера

Да, но я почти наверняка уверен, что кластерные решения рассчитаны на две сетевухи в ноде

Нет

1. Для клиента 2. Чтобы переливать данные между узлами

Это все на самом деле надо забывать. Если мы про облако

Ну, это проще, чем пытаться сделать qos

Твоя отдельная сетевуха будет бегать по тому же линку как vxlan

Это все на самом деле надо забывать. Если мы про облако

Ну, в облаке сложнее, Ога. Там все равно Вирт интерфейсы с прямым копированием данных прямо в озу, если вмки попали на одну ноду

Твоя отдельная сетевуха будет бегать по тому же линку как vxlan

В облаке интерфейсы 10 Гбит легко

Это на самом деле сложные вопросы выбора облаков под те или иные задачи

В облаке интерфейсы 10 Гбит легко

И делят полосу между сотнями клиентов ;)

Облака разные есть

Есть с 1гбит макс

А есть которые 10гбит дают в пределах одной ноды на интерконнект между вм

Это на самом деле сложные вопросы выбора облаков под те или иные задачи

Согласен

Все равно переплачиваешь, причем нехило