Мы настраиваем веб-ферму IIS7 с двумя серверами. Должен ли каждый сервер иметь свою собственную локальную копию контента или они должны извлекать контент непосредственно из общего ресурса UNC? Каковы плюсы и минусы каждого подхода?
В настоящее время у нас есть один действующий сервер WEB1, контент которого хранится локально в отдельном разделе. Задание периодически синхронизирует WEB1 с резервным сервером WEB2, используя robocopy для контента и msdeploy для config. Если WEB1 выходит из строя, Nagios уведомляет нас, и мы вручную запускаем скрипт для перемещения IP-адресов в сетевой интерфейс WEB2. Оба сервера фактически являются виртуальными машинами, работающими на отдельных хостах VMWare ESX 4. Серверы присоединены к домену.
У нас есть около 50-60 действующих сайтов на WEB1 - в основном ASP.NET, а некоторые представляют собой просто статический HTML. Большинство из них - "микросайты" с низким трафиком. У некоторых есть умеренный трафик, но нет ни одного массового.
Мы хотели бы изменить это, чтобы и WEB1, и WEB2 активно обслуживали контент. Это в основном для надежности - если WEB1 выходит из строя, мы не хотим вручную вмешиваться в работу при сбое. Распределение нагрузки тоже хорошо, но сейчас нагрузка недостаточно высока, чтобы нам это было нужно.
Мы планируем настроить наш брандмауэр для балансировки трафика между двумя серверами. Он обнаружит, когда сервер выходит из строя, и отправит весь трафик на оставшийся активный сервер. На данный момент мы планируем использовать липкие сеансы ... в конечном итоге мы можем перейти к состоянию сеанса SQL Server и балансировке нагрузки без сохранения состояния.
Но нам нужен способ для серверов обмениваться контентом. Изначально мы планировали переместить весь контент в общий ресурс UNC. Наш поставщик хранилищ говорит, что может настроить для нас высокодоступный общий ресурс SMB. Поэтому, если мы пойдем по маршруту UNC, хранилище не должно стать единственной точкой отказа. Но мы задаемся вопросом о недостатках этого подхода:
Нам нужно будет изменить физические пути для каждого сайта и виртуального каталога. Есть также проекты, у которых есть абсолютные пути в файлах web.config - нам также придется обновить их.
Нам нужно будет создать пользователя домена для веб-серверов для доступа к общему ресурсу и предоставить этому пользователю соответствующие разрешения. Я еще не изучал это - я не уверен, нужно ли изменить удостоверение пула приложений для этого пользователя, или есть другой способ указать IIS использовать эту учетную запись при подключении к общему ресурсу.
Сайты больше не смогут получить доступ к своему контенту, если когда-либо возникнет проблема с Active Directory.
В общем, это кажется намного более сложным, с большим количеством движущихся частей, которые могут сломаться. Наш поставщик хранилищ создаст для нас том в своей резервной сети SAN. Если я правильно понимаю, этот том SAN будет установлен на виртуальной машине, работающей в их избыточной среде VMWare; Затем эта виртуальная машина предоставит общий ресурс SMB нашим веб-серверам.
С другой стороны, преимущество подхода с общим контентом заключается в том, что нам нужно будет развернуть код только в одном месте, и никогда не будет временной несоответствия между несколькими копиями контента.
Эта ветка довольно интересно, хотя некоторые из этих людей работают в гораздо большем масштабе.
Я пока только что обсуждал контент, но нам также нужно подумать о конфигурации. Я не знаю, можем ли мы просто использовать репликацию DFS для applicationHost.config и других файлов, или лучше использовать общая конфигурация функция с конфигурацией на общем ресурсе UNC.
Что вы думаете?
Ваши опасения обоснованы, и в конце концов вам придется либо оценивать каждую награду с учетом унаследованных рисков.
Общий контент великолепен; но, как вы указали, в этом случае возникает зависимость от удаленного хоста, а технологии хранения в кластере не из дешевых или простых. У этого типа установки есть свое место, и, учитывая ваше текущее решение, я предполагаю, что вы не ищете решение безотказной работы 99,999%.
Думали ли вы о расширении вашего скрипта, чтобы отключить узлы с балансировкой нагрузки (на брандмауэре) в то время, когда вы синхронизируете контент из Web1> Web2?
Общая конфигурация, тем не менее, великолепна и использует копию локального кеша, если ваш общий ресурс UNC недоступен, и является отличным способом обеспечения правильной конфигурации веб-приложений.
Мои 2с
Некоторое время мы использовали общие ресурсы UNC для обслуживания кластерных (NLB) веб-заголовков, а недавно перешли на 64-битную ОС Win 2008R2, разница огромна, больше не нужно беспокоиться об исчерпании соединений SMB. Пределы есть, но они высоки. Я только что добавил DFS в смесь с другим файловым сервером, но пока не могу говорить о надежности.
Общий диск в сети SAN - лучшее решение, но лишь немного более реалистичное, чем полет на метле. Некоторые поставщики, такие как Melio, предлагают это, но с некоторыми большими недостатками (дорого, требуется SAN, если на VMware теряется возможность создания снимков с общим контроллером)
Использовать iSCSI в файловой системе общего диска ... UNC-ресурсы слишком медленные