Я планирую перенести свою небольшую среду общего хостинга на Amazon EC2. Для этого требуется центральное хранилище для веб-материалов (пока оставьте базы данных и т. Д. В стороне), чтобы я мог делать и то, и другое: балансировать нагрузку на веб-сайт по нескольким http-узлам и / или перемещать веб-сайт с одного узла на другой без фактического перемещения каких-либо данных.
В настоящее время мое хранилище находится на сервере NFS, доступ к которому повышается через pacemaker / heartbeat / drbd. Afaik, вы не можете работать с виртуальными IP-адресами в EC2, поэтому большинство решений HA выпадают. Остается GlusterFS (и Ceph, но сами заявляют, что не используют его в документации). Поэтому я бы установил два узла GlusterFS, каждый в отдельной зоне доступности, каждый монтировал несколько томов EBS (mdadm raid 10 для производительности и паранойи) и реплицировал друг на друга. Каждый клиент будет знать об обоих узлах экспортера, и если один из них выйдет из строя, само хранилище все равно будет работать.
Пока все хорошо (или нет?). Теперь возникает проблема: из моего понимания GlusterFS элементы управления доступом - это списки hosts.allow / .deny на основе томов. Чтобы уменьшить влияние поврежденного HTTP-узла, я хотел бы ограничить доступ каждого узла к хранилищу к корневым веб-сайтам веб-сайтов, которые он фактически обслуживает.
Позвольте мне прояснить это на примере моей текущей настройки NFSv4 + mount-bind:
На httpnode1
это веб-сайты, которые он обслуживает
* domain1.tld
* domain5.tld
* domain10.tld
экспорт nfs в / etc / fstab
10.0.0.1:/ /srv/web nfs4 rw,..
О экспортере NFS
структура
* /srv/storage << here are all websites
* /srv/export/httpnode1/ << webroots for httpnode1
* /srv/export/httpnode1/domain1.tld/ << mount-bind of /srv/storage/domain1.tld/
* /srv/export/httpnode1/domain5.tld/ << mount-bind of /srv/storage/domain5.tld/
* /srv/export/httpnode1/domain10.tld/ << mount-bind of /srv/storage/domain10.tld/
* /srv/export/httpnode2/ << webroots for httpnode2
* /srv/export/httpnode2/domain31.tld/ << mount-bind of /srv/storage/domain3.tld/
* /srv/export/httpnode2/domain5.tld/ << mount-bind of /srv/storage/domain5.tld/
/ etc / exports
# httpnode1
/srv/export/httpnode1 10.0.0.123(rw,..,fsid=0,crossmnt)
/srv/export/httpnode1/domain1.tld 10.0.0.123(rw,..)
/srv/export/httpnode1/domain5.tld 10.0.0.123(rw,..)
/srv/export/httpnode1/domain10.tld 10.0.0.123(rw,..)
# httpnode2
/srv/export/httpnode2 10.0.0.192(rw,..,fsid=0,crossmnt)
/srv/export/httpnode2/domain3.tld 10.0.0.192(rw,..)
/srv/export/httpnode1/domain5.tld 10.0.0.123(rw,..)
Что я могу придумать, пока что есть только одно решение с EC2 + EBS + GlusterFS - это экспорт нескольких томов из GlusterFS: по одному на каждый HTTP-узел.
Есть ли у кого-нибудь опыт работы с этим (например, требования к ресурсам в нескольких сотнях экспортированных томов) и как выглядят ваши конфигурации для этого? Или даже лучше: есть ли какой-нибудь элегантный подход к достижению моих целей?
Спасибо за понимание!
Приветствует Йорга
Мой опыт работы с блеском в EC2 был менее чем выдающимся. Я увидел ОГРОМНЫЕ проблемы с производительностью и в конечном итоге полностью избавился от блеска. Короче ... если между узлами задержка 1-2 мс ... gluster пострадает в геометрической прогрессии. Это была довольно маленькая установка, в которой было всего 2 узла. Мне бы очень не хотелось видеть, есть ли у вас больше узлов или долей.
Мое решение состояло в том, чтобы переключиться на унисон и репликацию между экземплярами ... но я честно понимаю, что это может быть не идеально для многих ситуаций.
Рассматривали ли вы в качестве альтернативного решения использование s3 bucket & s3fs? Это можно легко разделить между узлами.