Я не эксперт в облачных вычислениях - я потратил немало времени на изучение этого и различных поставщиков, но еще не получил практического опыта с ними. Однако из того, что я читал об AWS и автоматическом масштабировании экземпляров EC2, кажется, что каждый экземпляр должен быть полностью отделен от всех других экземпляров. то есть, если контент загружается в локальную файловую систему веб-сервера из настраиваемой серверной части CMS, то этот контент не будет доступен, если впоследствии будет запрошен с другого веб-сервера в группе автоматического масштабирования. Это правильно?
Недавно я встречался с представителем нашего существующего хостинг-провайдера, и он утверждал, что это не проблема, что наша устаревшая система CMS сильно зависит от наличия локальной файловой системы. Он сказал, что все веб-серверы, независимо от их количества, будут храниться как точные дубликаты, поэтому я не должен замечать никакой разницы по сравнению с нашей существующей настройкой одного выделенного сервера. Для меня это слишком пахнет бычьими фекалиями ... должен ли я относиться к этому скептически? Я немного волнуюсь, потому что мой (нетехнический) босс, который в конечном итоге принимает решения, полностью согласен с тем, чтобы подписаться на это облачное решение, потому что оно не требует дополнительной работы.
Я уверен, что они, по крайней мере, должны иметь возможность предоставить это, иначе они бы не пытались нам это продать. Но какой ценой? Похоже, что каждый веб-сервер всегда должен будет проверять другой веб-сервер на наличие нового статического контента, что для меня звучит как нежелательные накладные расходы, которые замедляют работу.
Я был бы очень признателен, если бы кто-нибудь мог прояснить это мне. Я полностью за то, чтобы перейти на AWS и использовать S3 + CloudFront для всего статического контента, но в настоящий момент это маловероятно.
Я не хочу показаться «нахальным» или беспечным, но это зависит от сервиса и цены. Можно выполнять репликацию файловой системы и блочную репликацию на устройствах SAN. Вам нужно будет спросить своего провайдера, используют ли они любую из этих двух технологий ... и вам нужно знать расстояние между сайтами репликации. Расстояние между реплицируемыми сайтами изменит степень репликации систем. Репликация через SAN будет вам дорого стоить. Репликация через службу или файловую систему может быть бесплатной (если они реплицируются через rsync или что-то еще).
Если вы говорите о статических файлах, есть кластерные реплицированные решения, такие как Gluster что позволит сделать это относительно легко и с довольно разумными накладными расходами.
Однако вы, вероятно, не захотите запускать на нем что-то вроде базы данных MySQL.
Чтобы обслуживать приложение, которое полагается на согласованную внутреннюю файловую систему, синхронизация должна быть всенаправленной и блокировать любые запросы на запись до тех пор, пока все копии не будут обновлены ... очень сложное дело, чтобы заставить работать правильно, мягко говоря, и любые внутренние ошибка такой системы будет иметь катастрофические последствия.
Вероятно, они действительно управляют всеми вашими веб-головами из единого массивного внутреннего хранилища (NFS или SAN с учетом файловой системы), что может привести к единой точке отказа.