У нас storage и compute как раз объединены. То есть на одном сервере могут быть расположены как машины клиентов, так и узлы хранения (chunk и mds). Можно даже весь PCS целиком разместить в виртуалке.
Снэпшот метаданных MDS не имеет никакого отношения к данным, которые пишет пользователь. MDS-метаданные реплицируются в количестве запущенных MDS-серверов. Мы рекомендуем 3 или 5 серверов в зависимости от размера кластера, что позволяет пережить потерю до одного или двух MDS-серверов.
Вполне. Хотя, конечно, если на каждом сервере по 8 дисков, то лучше уже 10 Гбит. В случае с 1 Гбит вы будете ограничены 100 Мб/сек., но прелесть в том, что обычно за редким исключением приложения генерируют более-менее рандомную нагрузку на диск, и в ограничение сети вы вряд ли упретесь. 95% машин, которые мы проанализировали в 6 дата-центрах, имеют в среднем всего лишь 20-30 Мб/сек., при том что в них, как правило, RAID и несколько дисков.
Принципиально от GlusterFS отличается тем, что рассчитан на выживание в условиях сбоев. GlusterFS по сути не поддерживает никаких знаний о том, какие части файлов рассинхронизовались и какая из копий актуальна, а какая устарела. Легко продемонстрировать, как в случае сбоев читаются устаревшие данные и даже размер файла пляшет в зависимости от того, кто его возвращает. А после сбоя GlusterFS может синхронизовать целиком гигансткие файлы, при том что изменился лишь один байт.
Пока идея такая, чтобы использовать строрадж с нашей виртуализацией. А потом посмотрим. Не исключено, что появится отдельная версия с поддержкой KVM/XEN. Если задумаем делать, будете бета-тестерами?
Parallels Cloud Server сдается в лизинг, провайдер перечисляет ежемесячные платежи.
PCS лицензируется следующим образом:
1) По максимальному количеству одновременно запущенных виртуальных машин и/или контейнеров для каждого узла с ними;
2) По количеству серверов в хранилище (с ролями Chunk и/или MDS);
3) По объему сырого дискового пространства в хранилище. Чем больше хранилище, тем дешевле за каждый гиг.
Реплицируется с помощью распределенного журнала работающего на базе протокола Paxos.
> Как сказываются на записи небольшие потери пакетов, вызывающие в итоге ретрансмиты?
Как с любым видом трафика и протокола — не в положительную сторону. Клиентам предлагается использовать выделенную сеть для трафика хранилища, чтобы изолировать ее от пользовательского трафика, в целях безопасности и избежания DDoS-атак.
По умолчанию используется TCP.
> Кто апдейтит в MDS запись о том, что какой-то сервер не смог себе записать кусочек?
Клиент.
> Если апдейтим 1 байт, то сохранять надо будет весь 64-мегабайтный кусок?
Мы посмотрели на статистику Windows 8 внутри Parallels Desktop. Предрелизную версию «восьмерки» скачали более полумиллиона раз. Да, многие качали «на попробовать», но часть пользователей все равно осталась бы на Win8. В их числе — разработчики. Их надо поддержать. Примерно такая логика.
> Можно ли настроить мониторинг нагрузки и автоматически добавлять ресурсы, а при снижении нагрухки — автоматически уменьшать?
Пока такой возможности out-of-box нет. Есть интерфейсы API, которые позволяют самостоятельно написать скрипты для добавления и уменьшения ресурсов и даже создания нового сервера.
> Можно ли при этом отслеживать расход средств, чтобы не вылететь в трубу?
Зависит от того, какие скрипты напишет пользователь. Статистика по использованию ресурсов обновляется каждый час, проверять ее можно из панели управления.
> Можно ли поднимать инстансы из своих образов как на амазоне? А автоматически, при росте нагрузки? Есть ли свой балансировщик? (я прицеливаюсь поставить Битрикс-Кластер)
Делать свои образы можно. Создавать из них новые серверы можно с помощью API, но автоматически это сейчас не делается (см. первый вопрос). Балансировщик http есть (на основе Linux).
Сложно говорить о весовой доле каждого из вариантов использования, поскольку каждый из них самостоятелен и имеет свои особенности применения. Например, непросто оценить эффективность использования Spider Tool, запускаемого на клиентских серверах. Мы не знаем, какие статьи KB там показываются на основании сканирования логов клиентского Плеска. Вариант номер три вообще, используется тогда, когда тикет уже создан.
Могу лишь сказать, что вариант три, на мой взгляд, дает наибольшее количество найденных статей, поскольку в теле тикета весьма много информации содержащей разные сигнатуры. Вариант два тоже должен давать достаточно большой список статей, поскольку в многочисленных сканируемых логах тоже много возможных сигнатур. У варианта один самый меньший объем входящей информации, поэтому он наименее продуктивен, но зато наиболее важен в деле отсечения потока входящих в саппорт тикетов.
Да, конечно, для старых статей добавлялись сигнатуры. Сбор и добавление сигнатур для старых статей осуществлялись несколькими сотрудниками в течении некоторого времени.
Сигнатур сейчас более 7000.
PCS лицензируется следующим образом:
1) По максимальному количеству одновременно запущенных виртуальных машин и/или контейнеров для каждого узла с ними;
2) По количеству серверов в хранилище (с ролями Chunk и/или MDS);
3) По объему сырого дискового пространства в хранилище. Чем больше хранилище, тем дешевле за каждый гиг.
И да, лицензии можно докупать по мере роста.
> Как реплицируется MDS?
Реплицируется с помощью распределенного журнала работающего на базе протокола Paxos.
> Как сказываются на записи небольшие потери пакетов, вызывающие в итоге ретрансмиты?
Как с любым видом трафика и протокола — не в положительную сторону. Клиентам предлагается использовать выделенную сеть для трафика хранилища, чтобы изолировать ее от пользовательского трафика, в целях безопасности и избежания DDoS-атак.
По умолчанию используется TCP.
> Кто апдейтит в MDS запись о том, что какой-то сервер не смог себе записать кусочек?
Клиент.
> Если апдейтим 1 байт, то сохранять надо будет весь 64-мегабайтный кусок?
Нет. 1 байт апдейтит 1 байт в каждой реплике.
Пока такой возможности out-of-box нет. Есть интерфейсы API, которые позволяют самостоятельно написать скрипты для добавления и уменьшения ресурсов и даже создания нового сервера.
> Можно ли при этом отслеживать расход средств, чтобы не вылететь в трубу?
Зависит от того, какие скрипты напишет пользователь. Статистика по использованию ресурсов обновляется каждый час, проверять ее можно из панели управления.
> Можно ли поднимать инстансы из своих образов как на амазоне? А автоматически, при росте нагрузки? Есть ли свой балансировщик? (я прицеливаюсь поставить Битрикс-Кластер)
Делать свои образы можно. Создавать из них новые серверы можно с помощью API, но автоматически это сейчас не делается (см. первый вопрос). Балансировщик http есть (на основе Linux).
Могу лишь сказать, что вариант три, на мой взгляд, дает наибольшее количество найденных статей, поскольку в теле тикета весьма много информации содержащей разные сигнатуры. Вариант два тоже должен давать достаточно большой список статей, поскольку в многочисленных сканируемых логах тоже много возможных сигнатур. У варианта один самый меньший объем входящей информации, поэтому он наименее продуктивен, но зато наиболее важен в деле отсечения потока входящих в саппорт тикетов.
Сигнатур сейчас более 7000.