В таблице в конце статьи приведены характерные задержки (latency) при обработке единичного запроса PUT. С S3 хранилищем можно и нужно работать с параллельной нагрузкой. Например при загрузке объекта использовать multipart upload (многосоставную загрузку объекта во множество параллельных потоков). Суммарно несколько потоков загрузки одного объекта дадут производительность кратно выше. За счёт этого и достигается линейное масштабирование производительности S3. Кстати, тут можно посмотреть на эксперименты с параллельными запросами и как это влияет на скорость загрузки в S3 на реальных примерах: https://www.youtube.com/watch?v=nBYQqLUyYXo
Сервис MDS имеет высокую доступность; метаданные реплицируются между MDS. Один MDS выбирается master. Он принимает решения (например, обновление map для какого-то файла). Приняв решение, он коммитит его в свой журнал и рассылает его по slave MDS. MDS отправляет результат клиентам только после того как большинство(majority) MDS ответило о коммите транзакции в журнал. Кластер работает пока MDS majority остаётся on-line. Мы рекомендуем иметь 5 MDS в кластере, чтобы сохранить majority в случае выхода их строя одновременно двух MDS.
Если поместить MDS на SSD, то он способен выдавать около 30K файловых операций в секунду (таких как открытие файла, выделение нового chunk и т.д.) на одно процессорное ядро. Этой производительности вполне достаточно для кластеров в несколько тысяч работающих VM и контейнеров. Объясню чуть подробнее почему. I/O работает независимо от MDS, кластер может выдавать миллионы IOPS, оказывая минимальную нагрузку на MDS. Файл на Virtuozzo Storage – это образы виртуальных машин и контейнеров, либо больше volumes для сервисов, таких как S3, iSCSI, NFS. То есть все они – это несколько больших файлы, которые редко переоткрываются. Работа c объектами/файлами пользовательского представления (фалы в VM, объекты в S3, файлы на NFS шаре) происходит на уровне выше и не затрагивает MDS.
Бекары надо делать всегда, для любой системы, какой бы она ни была (хоть Software, хоть Hardware).
В прошивках RAID контроллеров тоже бывают ошибки. В RAM могу меняться биты… А в жизни бывают и цунами, и человеческий фактор.
Для этого и пишется много различного софта для HA.
Virtuozzo Cloud Storage позволяет защититься не только от потери дисков в кластере, ошибок на этих дисках, но и вообще от полной потери одного или нескольких физических серверов с сохранением strong-consistency хранимых данных и доступа к этим данным. От всего остального Вас убережет бекап.
Odin Virtuozzo Cloud Storage состоит из 3х конмпонент: CS, MDS и client. Client — это FUSE-mount, компонент, принимающий запросы к данным от виртуальных машин. CS хранит сами данные. MDS «дирижирует» процессом.
SSD (будь то PCS-e или нет) используется в Odin Virtuozzo Cloud Storage для двух целей: write-back journaling (для ускорения операций записи на CS-ах) и read-cache (для ускорения операций чтения на клиентах).
Про чексуммы Write-back journaling:
Все операции записи в Storage кластер изначально записываются в журнал на SSD, где им присваивается SHA-хеш для каждого 4К блока данных. Это позволяет надежно и быстро обрабатывать операции записи. Затем, CS в фоне, перекладывает данные с SSD на HDD, осуществляя различные оптимизации (например, склеивает несколько последовательных мелких записей в одну большую).
Когда CS читает данные с HDD, то всегда сравнивает хеш, того, что прочитал с вращающегося диска с эталонным, хранящимся на SSD. Кроме этого реализован scrubbing, когда CS самостоятельно переодически вычитывает данные с HDD и проверяет действительно ли HDD по-прежнему содержит валидные данные. Тем самым, система защищается от «молчаливых сбоев» на дисках.
Проверил логи. Ошибки нет. Это — предмет для исследований. Спасибо, что заметили.
В приведённом документе тесты были на PCS6 (Это Linux kernel 2.6.32) и версии PStorage 6.0.0-789, а в комментах RHEL7 (Это Linux kernel 3.10) и версии PStorage 6.0.7-32. Что-то могло в это время поменяться. Сейчас не могу сказать что именно привело к улучшению — нужно исследовать.
Да, можно будет попробовать и такой сценарий. К сожалению, полного сета измерений для разного объема данных не могу сейчас привести. Мы выбирали 16GB из статистики и компромисса времени работа теста, чтобы успеть измерить все сценарии. Но еще раз подчеркну, что PStorage обеспечивает строгую консистентность данных, а значит в тесте write()+fdatasync() RAM кэш не влияет.
В следующий раз по-тестируем с большим объемом данных, почему бы и нет. :)
Кстати, о кэшах. Да, тест с полностью отключенными кэшами имеет смысл. Но, ведь в реальной жизни вы ими пользуетесь! Вопрос в том работают ли они для вашей именно задачи.
Наверное, я несколько запутал… Посмотрите, пожалуйста, на графики в этом документе. Там они разделены на горизонтальную и вертикальную масштабируемость.
Вы сравниваете не «яблоки с яблоками». :) В посте показана масштабируемость IOPS с ростом кластра. Сравнивается 16 поточная нагрузка на кластере из одной, 10 и 21 ноды. В комментах картинка показывает производительность с ростом нагрузки (1, 4 и 16 потоков) на кластере фиксированного размера.
:) Я думаю, что они посмотрят на картинку с графиками в комментах. Посмотрят и оценят у кого медленнее. :)
А если серьезно. Да, в FUSE есть проблемы, мы их справили. Parallels довольно много сделала патчей в mainstream чтобы сделать FUSE быстрым.
16GB это средний working set на VM с ноды. Он разделен на 16 файлов по 1GB (1GB горячих данных на VM), чтобы каждый поток грузил свой файл. Один нагрузочный поток — VM.
4K — это минимальная дискретизация данных, она показывает IOPS системы. Тесты с большим блоком показывает пропускную способность.
8K тоже мереть можно, если для вашей системы актуально. Вообще стоит мереть именно актуальную нагрузку для конкретной системы. Идеально — вообще снять дамп IO запросов c рабочей системы и прогнать. :)
Обычно у VM гораздо больше записи чем чтения, больше случайного I/O чем последовательного. И обычно случайное I/O это запросы до 32K.
Конфигурация: сеть — 10Gbit (увидел ошибку в описании и решил описать подробно), 5 нод, на каждой Core i5, 16G Mem, 3 диска SATA 7200 RPM + один 100G SSD, который использовался для кеширования/журналирования (osd-journals, monitors, write-back) в CEPH и в PStorage.
OC одна — RHEL 7, в обоих случаях ;)
Да.
Только Parallels Cloud Storage архитектурно ориентирован на хранение больших файлов (>256MB), таких как образы виртуальных машин, базы данных, video, backup, log и прочее. Благодаря такой архитектуре он показывает отличную производительность. Максимальный объем одного кластера — до 8000 ТБ.
Хочу отметить, что PStorage сейчас может хранить файлы вообще любого объема (как большие так и маленькие). Но если записать миллионы-миллирды мелких(!) файлов, то производительность будет уже совсем не такой. Мелкие файлы эффективнее хранить как объекты (Object Storage), а не как файлы. Это уже будущая фича PStorage. NAS сценарий для мелких файлов мы обязательно покроем в следующих релизах. Пока только NAS для больших файлов…
Также PStorage гарантирует строгую консистентность данных, которая очень нужна для виртуализации и БД.
Консистентность будет подробнее описана в следующем посте, так как это отдельная глубокая тема: как её достичь и сохранить производительность. Забегая вперед, скажу, что PStorage возвращает ack, когда записал все три копии на разные машины.
Кстати, у нас даже специальный процесс тестирования для этого построен, когда пишем данные и зовём sync, затем вырубаем всю или часть системы, и проверяем, что данные действительно записались.
16ГБ — это примерный объем данных, с которыми работают виртуальные машины на ноде.
Я понимаю ваши опасения насчет OС-кешей, но эти кеши легко отключаемы почти в любой I/O тестилке. И по-моему, все уже меряют aio или directio. Кстати, в приведенных результатах OS writeback в принципе не мог работать ни на каком уровне, еще и потому, что в операциях записи после каждого write() зовелся fdatasync(). А sync в PStorage гарантирует, что данные реально записаны на дисках на разных машинах.
Время теста должно быть продолжительным — сколько хотите. Просто в регулярном тестировании сложно ждать бесконечность (что было бы идеальным), чтобы промерять все сценарии.
В таблице в конце статьи приведены характерные задержки (latency) при обработке единичного запроса PUT. С S3 хранилищем можно и нужно работать с параллельной нагрузкой. Например при загрузке объекта использовать multipart upload (многосоставную загрузку объекта во множество параллельных потоков). Суммарно несколько потоков загрузки одного объекта дадут производительность кратно выше. За счёт этого и достигается линейное масштабирование производительности S3. Кстати, тут можно посмотреть на эксперименты с параллельными запросами и как это влияет на скорость загрузки в S3 на реальных примерах: https://www.youtube.com/watch?v=nBYQqLUyYXo
Если поместить MDS на SSD, то он способен выдавать около 30K файловых операций в секунду (таких как открытие файла, выделение нового chunk и т.д.) на одно процессорное ядро. Этой производительности вполне достаточно для кластеров в несколько тысяч работающих VM и контейнеров. Объясню чуть подробнее почему. I/O работает независимо от MDS, кластер может выдавать миллионы IOPS, оказывая минимальную нагрузку на MDS. Файл на Virtuozzo Storage – это образы виртуальных машин и контейнеров, либо больше volumes для сервисов, таких как S3, iSCSI, NFS. То есть все они – это несколько больших файлы, которые редко переоткрываются. Работа c объектами/файлами пользовательского представления (фалы в VM, объекты в S3, файлы на NFS шаре) происходит на уровне выше и не затрагивает MDS.
В прошивках RAID контроллеров тоже бывают ошибки. В RAM могу меняться биты… А в жизни бывают и цунами, и человеческий фактор.
Для этого и пишется много различного софта для HA.
Virtuozzo Cloud Storage позволяет защититься не только от потери дисков в кластере, ошибок на этих дисках, но и вообще от полной потери одного или нескольких физических серверов с сохранением strong-consistency хранимых данных и доступа к этим данным. От всего остального Вас убережет бекап.
SSD (будь то PCS-e или нет) используется в Odin Virtuozzo Cloud Storage для двух целей: write-back journaling (для ускорения операций записи на CS-ах) и read-cache (для ускорения операций чтения на клиентах).
Про чексуммы Write-back journaling:
Все операции записи в Storage кластер изначально записываются в журнал на SSD, где им присваивается SHA-хеш для каждого 4К блока данных. Это позволяет надежно и быстро обрабатывать операции записи. Затем, CS в фоне, перекладывает данные с SSD на HDD, осуществляя различные оптимизации (например, склеивает несколько последовательных мелких записей в одну большую).
Когда CS читает данные с HDD, то всегда сравнивает хеш, того, что прочитал с вращающегося диска с эталонным, хранящимся на SSD. Кроме этого реализован scrubbing, когда CS самостоятельно переодически вычитывает данные с HDD и проверяет действительно ли HDD по-прежнему содержит валидные данные. Тем самым, система защищается от «молчаливых сбоев» на дисках.
В приведённом документе тесты были на PCS6 (Это Linux kernel 2.6.32) и версии PStorage 6.0.0-789, а в комментах RHEL7 (Это Linux kernel 3.10) и версии PStorage 6.0.7-32. Что-то могло в это время поменяться. Сейчас не могу сказать что именно привело к улучшению — нужно исследовать.
В следующий раз по-тестируем с большим объемом данных, почему бы и нет. :)
Кстати, о кэшах. Да, тест с полностью отключенными кэшами имеет смысл. Но, ведь в реальной жизни вы ими пользуетесь! Вопрос в том работают ли они для вашей именно задачи.
А если серьезно. Да, в FUSE есть проблемы, мы их справили. Parallels довольно много сделала патчей в mainstream чтобы сделать FUSE быстрым.
4K — это минимальная дискретизация данных, она показывает IOPS системы. Тесты с большим блоком показывает пропускную способность.
8K тоже мереть можно, если для вашей системы актуально. Вообще стоит мереть именно актуальную нагрузку для конкретной системы. Идеально — вообще снять дамп IO запросов c рабочей системы и прогнать. :)
Обычно у VM гораздо больше записи чем чтения, больше случайного I/O чем последовательного. И обычно случайное I/O это запросы до 32K.
Я про картинку в комментах, там в правом нижнем углу красным подчеркнуто 1Gbit. Должно быть 10.
OC одна — RHEL 7, в обоих случаях ;)
Только Parallels Cloud Storage архитектурно ориентирован на хранение больших файлов (>256MB), таких как образы виртуальных машин, базы данных, video, backup, log и прочее. Благодаря такой архитектуре он показывает отличную производительность. Максимальный объем одного кластера — до 8000 ТБ.
Хочу отметить, что PStorage сейчас может хранить файлы вообще любого объема (как большие так и маленькие). Но если записать миллионы-миллирды мелких(!) файлов, то производительность будет уже совсем не такой. Мелкие файлы эффективнее хранить как объекты (Object Storage), а не как файлы. Это уже будущая фича PStorage. NAS сценарий для мелких файлов мы обязательно покроем в следующих релизах. Пока только NAS для больших файлов…
Также PStorage гарантирует строгую консистентность данных, которая очень нужна для виртуализации и БД.
Кстати, у нас даже специальный процесс тестирования для этого построен, когда пишем данные и зовём sync, затем вырубаем всю или часть системы, и проверяем, что данные действительно записались.
16ГБ — это примерный объем данных, с которыми работают виртуальные машины на ноде.
Я понимаю ваши опасения насчет OС-кешей, но эти кеши легко отключаемы почти в любой I/O тестилке. И по-моему, все уже меряют aio или directio. Кстати, в приведенных результатах OS writeback в принципе не мог работать ни на каком уровне, еще и потому, что в операциях записи после каждого write() зовелся fdatasync(). А sync в PStorage гарантирует, что данные реально записаны на дисках на разных машинах.
Время теста должно быть продолжительным — сколько хотите. Просто в регулярном тестировании сложно ждать бесконечность (что было бы идеальным), чтобы промерять все сценарии.