Поэтому мы рассматриваем возможность переноса нашего единственного выделенного сервера (настроенного как общий веб-хостинг) на архитектуру с несколькими интерфейсными серверами с балансировкой нагрузки и отдельными серверами баз данных (из-за роста трафика и проблем с доступностью).
TL; DR; Мне нужен способ переключения на локальное зеркало, доступное только для чтения, файлов сайта, когда файловый сервер выходит из строя.
Сценарий:
Цели / требования:
Я понимаю, что типичным подходом было бы развертывание через контроль версий, что мы уже делаем в некоторых случаях, но наши сотрудники (не разработчики, которые в основном управляют баннерами, текстовыми обновлениями и т. Д.) Довольно привыкли к рабочему процессу "FTP" , который я хотел бы изменить, но, возможно, еще не сейчас.
Вот решения, которые я придумал:
На файловом сервере размещается «основная» копия файлов сайта, к которым можно получить доступ через FTP, и она предоставляет их через сервер rsync. У меня есть какой-то интерфейс «развертывания», который запускает каждый сервер переднего плана для синхронизации сайта и «развертывания».
Плюсы
Минусы
Файловый сервер NFS с локальным кешем, периодически выполняющий синхронизацию локальной резервной копии, а затем, возможно, отработку отказа путем переключения точки монтирования привязки на локальную резервную копию.
Плюсы
Минусы
Я не очень хорошо знаком с этим вариантом, но считаю, что это общий подход, когда у вас большое количество серверов. Я просмотрел некоторую документацию, и она может быть подходящей, но я не вижу, чтобы многие люди рекомендовали ее в таком маленьком масштабе.
Плюсы
Минусы
Спасибо за ваши ответы, ребята, я начинаю понимать, что делаю слишком сложные вещи, учитывая (относительно небольшой) масштаб моих потребностей. Я думаю, что правильным решением в моем случае является то, что мне нужно ввести явное событие «развертывания», которое запускает обновление локальных файлов, эфира из системы контроля версий или какого-либо другого источника.
Хотя файлы обновляются регулярно, при распределении по ~ 200 сайтам реальность такова, что маловероятно, что большинство сайтов будут обновляться чаще, чем раз в месяц, поэтому наличие механизма для мгновенной синхронизации любых произвольных изменений в любом файле в любое время кажется ненужным.
В одной подобной установке, которую я выполняю, у меня есть настройка gluster таким образом, чтобы каждый веб-сервер имел полную копию данных. Это означает, что чтение никогда не должно проходить по сети и, если это идеально для нас, - довольно небольшой объем данных с нечастой записью.
Volume Name: gv0
Type: Replicate
Volume ID: 1f70af9d-4caa-4d2d-8dbd-feedfacebeef
Status: Started
Number of Bricks: 1 x 6 = 6
Transport-type: tcp
Bricks:
Brick1: server1:/export/glusterfs
Brick2: server2:/export/glusterfs
Brick3: server3:/export/glusterfs
Brick4: server4:/export/glusterfs
Brick5: server5:/export/glusterfs
Brick6: server6:/export/glusterfs
Звучит в самый раз!
Сложные мысли ... Но вы можете слишком усложнять вещи.
Думать об этом. При каких обстоятельствах ваш сервер NFS "выйдет из строя"? От какого конкретного режима отказа вы пытаетесь защититься? Разве часть этого не смягчается платформой хранения и виртуализации поставщика облачного хостинга?
Я фанат NFS для этой цели. Имейте в виду, что это, как правило, аппаратное обеспечение хранения без операционной системы, которое может иметь достаточную внутреннюю отказоустойчивость, чтобы выдерживать обычные отказы. Но вы планируете развертывание в облаке.
Итак, я бы представил кластерные балансировщики нагрузки перед уровнем вашего веб-сервера, поддерживаемые кластеризованным хранилищем NFS. В хранилище NFS должен быть виртуальный IP (VIP) к веб-хостам. Распространенный подход - использование DRBD и Кардиостимулятор, но есть и другие варианты.
Резервный сервер NFS, который периодически синхронизируется, может быть вариантом.
Вы можете использовать DNS-имена для монтирования NFS и использовать Маршрут 53 (вручную или автоматически), чтобы изменить целевой IP-адрес, если вы потеряете основное хранилище.
Пара идей. Я стараюсь избегать полноценных кластерных файловых систем для веб-решений, но они также могут быть вариантами.