Назад |
Перейти на главную страницу
какая распределенная файловая система для двухузловой настройки аварийного переключения?
Я пытаюсь создать резервную копию, состоящую из два сервера которые имеют все избыточное:
- база данных (MySQL master-master в активном / пассивном режиме)
- файловая система (распределенная / реплицированная)
- наше прикладное программное обеспечение (синхронизируется с помощью распределенной файловой системы)
В основном один из двух серверов будет «основным» сервером, а другой будет реплицировать все свои данные и также будет использоваться для распределения рабочей нагрузки (Gearman). В случае отказа основного сервера все переключается на «резервный» сервер, который станет «активным» и продолжит свою работу.
Чтобы снизить риск полного отказа обоих серверов, они географически отделен в двух удаленных дата-центрах (одна страна / прямые подключения).
Я много читал о распределенных файловых системах, но до сих пор не знаю, какое решение подходит всего для двух узлов ...
Еще несколько требований к распределенной файловой системе:
- должен быть совместим с POSIX
- должен копировать все (все данные должны быть доступны на обоих серверах постоянно) в оба направления (все данные можно изменить где угодно)
- текущая статистика, относящаяся к уже существующим данным, которая должна быть воспроизведена в будущем:
- около 30 ГБ данных, постоянно растет с 3 лет
- около 3 миллиона файлов в 7500 каталогах
- средний размер файла прибл. 5-10 кб; есть несколько больших файлов размером около 10-50 МБ
- файлы обычно добавляются периодически в течение дня и перемещаются в другой каталог после обработки (аналогично почтовому серверу на основе файлов)
- раз в сутки несколько тысяч файлов (полученных накануне) архивируются в несколько архивов TAR и остаются там «навсегда»
- при добавлении файлов данные сначала записываются во временный файл, начинающийся с точки "." а затем переименован по завершении. Только в редких случаях существующий файл изменяется.
- система должна хорошо справляться с непредвиденными потерями соединения, перезагрузками сервера и т. д.
- нет проблем, если репликация задерживается на 1-2 секунды, но она всегда должна быть в согласованном состоянии
- как сказано, дистр. filesys. будет состоять всего из двух узлов, но было бы большим бонусом, если бы я мог добавить дополнительные узлы / серверы, если мне понадобится больше вычислительной мощности в будущем
Обновление / подробнее:
- Мне просто нужна избыточность в смысле «файлы, хранящиеся на обоих серверах, синхронизируются немедленно». При доступе к файлам мне не нужна файловая система для чтения данных с другого сервера только потому, что локальные жесткие диски выходят из строя. Когда локальный жесткий диск выходит из строя, вся серверная машина считается «сломанной» и поэтому должна прекратить свою работу.
Какая файловая система подходит для этого сценария?
XtreemFS кажется, это то, чего вы хотите достичь. Вероятно, вы можете делать то же самое с CephFS.
Попробуйте DRBD. Это не файловая система, а блочное устройство.
Из http://lwn.net/Articles/329543/
Протокол A: Запись считается завершенной, как только запись на локальный диск завершена и пакет данных помещен в очередь отправки для одноранговых узлов. В случае отказа узла может произойти потеря данных, поскольку данные, которые должны быть записаны на диск удаленного узла, могут все еще находиться в очереди на отправку. Однако данные на отказоустойчивом узле согласованы, но не актуальны. Обычно это используется для географически разделенных узлов.
...
Одиночный первичный: первичное обозначение дается одному члену кластера. Поскольку только один член кластера управляет данными, этот режим полезен с обычными файловыми системами, такими как ext3 или XFS.
Смотрите также http://www.drbd.org/home/feature-list/ Больше подробностей.