Как стать автором
Обновить

Комментарии 33

Как реплицируется MDS и на сколько сказываются задержки меж-дц линков? Как сказываются на записи небольшие потери пакетов, вызывающие в итоге ретрансмиты? Кто апдейтит в MDS запись о том, что какой-то сервер не смог себе записать кусочек? Если апдейтим 1 байт, то сохранять надо будет весь 64-мегабайтный кусок?

В общем, хочется подробностей, как собственно запись то идёт.
По порядку.

> Как реплицируется MDS?

Реплицируется с помощью распределенного журнала работающего на базе протокола Paxos.

> Как сказываются на записи небольшие потери пакетов, вызывающие в итоге ретрансмиты?

Как с любым видом трафика и протокола — не в положительную сторону. Клиентам предлагается использовать выделенную сеть для трафика хранилища, чтобы изолировать ее от пользовательского трафика, в целях безопасности и избежания DDoS-атак.
По умолчанию используется TCP.

> Кто апдейтит в MDS запись о том, что какой-то сервер не смог себе записать кусочек?

Клиент.

> Если апдейтим 1 байт, то сохранять надо будет весь 64-мегабайтный кусок?

Нет. 1 байт апдейтит 1 байт в каждой реплике.
Сколько будет стоить и как будет тарифицироваться?
Поддерживаю вопрос.
Parallels Cloud Server сдается в лизинг, провайдер перечисляет ежемесячные платежи.

PCS лицензируется следующим образом:
1) По максимальному количеству одновременно запущенных виртуальных машин и/или контейнеров для каждого узла с ними;
2) По количеству серверов в хранилище (с ролями Chunk и/или MDS);
3) По объему сырого дискового пространства в хранилище. Чем больше хранилище, тем дешевле за каждый гиг.

И да, лицензии можно докупать по мере роста.
Интересно, насколько дешевле получается такое решение по сравнению с энтерпзайзом?

И как в общем выглядит процесс интеграции системы? Понятно, что покупается куча железа для хранения данных, но что происходит с дисками, которые уже стоят в серверах с виртуалками?
Как вы оцениваете время снятия снепшопа памяти в 64Гб? Даже если на SSD?
200-600 секунд. Пока снимается снэпшот, система не стоит на месте. Это делается в бэкграунде.
Т.е. актуальность данных может отставать до 10 минут при падении?
Во время снэпшота данные при записи не уходят в обе «копии» ли?
Снэпшот метаданных MDS не имеет никакого отношения к данным, которые пишет пользователь. MDS-метаданные реплицируются в количестве запущенных MDS-серверов. Мы рекомендуем 3 или 5 серверов в зависимости от размера кластера, что позволяет пережить потерю до одного или двух MDS-серверов.
Нет, это снэпшот состояния MDS. Отставать он не может потому, что есть еще журнал. То есть текущее состояние — это снэпшот плюс журнал на диске.
Еще вопрос: какие минимальные/желательные требования к интерконнекту? Гигабитная сеть это ок?
Вполне. Хотя, конечно, если на каждом сервере по 8 дисков, то лучше уже 10 Гбит. В случае с 1 Гбит вы будете ограничены 100 Мб/сек., но прелесть в том, что обычно за редким исключением приложения генерируют более-менее рандомную нагрузку на диск, и в ограничение сети вы вряд ли упретесь. 95% машин, которые мы проанализировали в 6 дата-центрах, имеют в среднем всего лишь 20-30 Мб/сек., при том что в них, как правило, RAID и несколько дисков.
Круто! А где купить такой настенный светильник?
В личку отправил.
хранит полное состояние об объектах и их версиях в памяти

А если оба сервера MDS падают (отключили питание в стойке), то метаданным конец? Или предполагается что второй сервер MDS находится в другом месте?
Как написали выше, MDS синхронизируется по paxos, так что их как минимум 3 штуки. Опять же, не надо такие машины ставить в одну стойку! Они обязаны питаться от разных линий.
Ага, т.е. assumption таков, что как минимум один сервер выживет. Вполне норм.

А если все-таки все умрут, то он умеет как-то перестраивать свои данные из хранилища?
Чем принципиально ваш Cloud Storage отличается от glusterfs и можно ли его использовать отдельно от Parallels Cloud Server, скажем, с KVM/XEN?
Пока идея такая, чтобы использовать строрадж с нашей виртуализацией. А потом посмотрим. Не исключено, что появится отдельная версия с поддержкой KVM/XEN. Если задумаем делать, будете бета-тестерами?
С удовольствием :)
Тогда можно в личку координаты? Нам надо понять насчет вашей инфраструктуры кое-что.
Принципиально от GlusterFS отличается тем, что рассчитан на выживание в условиях сбоев. GlusterFS по сути не поддерживает никаких знаний о том, какие части файлов рассинхронизовались и какая из копий актуальна, а какая устарела. Легко продемонстрировать, как в случае сбоев читаются устаревшие данные и даже размер файла пляшет в зависимости от того, кто его возвращает. А после сбоя GlusterFS может синхронизовать целиком гигансткие файлы, при том что изменился лишь один байт.
НЛО прилетело и опубликовало эту надпись здесь
Не измеряли, какие скорости получаются на том же гигабите, при условии, что диски упираются не в него? Ну и результаты fio на последовательную/случайную запись с большими блоками были бы очень интересно увидеть.
Немного непонятно, с таким подходом для storage и compute всё равно используются разные физические сервера, так? А не думали над вариантом объединить storage и compute? То есть, вместо скажем 1U или блейд-серверов для машин клиентов и 2U-4U нод для стораджа, использовать 1U/2U ноды с дисками для всего вместе — диски и часть сетевых портов отделить для распределённого хранилища (можно даже сам сторадж сделать на virtual appliance с raw disk passthrough), а CPU и большую часть RAM оставить на контейнеры клиентов.
У нас storage и compute как раз объединены. То есть на одном сервере могут быть расположены как машины клиентов, так и узлы хранения (chunk и mds). Можно даже весь PCS целиком разместить в виртуалке.
Очень круто. Мы с партнёрами как раз рассматривали этот сегмент бизнеса.
Интересуют подробности. У вас уже есть какие-то рассчёты порога входного объёма данных для вашей системы и окупаемости?
Да, это всё считается под конкретного провайдера и его инфраструктуру. Если можно, ваши контакты в личку.
В opensource что-нибудь упадёт?
Какие клиентские интерфейсы доступны?
Зарегистрируйтесь на Хабре , чтобы оставить комментарий