Что плохого в запуске веб-приложения IIS из общего ресурса UNC, как это предлагается в документации DotNetNuke?

Есть несколько вещей, которые могут стать проблематичными, когда дело доходит до этого типа конфигурации с DOtNetNuke.

1. Этот метод, хотя сценарий «веб-фермы» приводит к единой точке отказа. Общий ресурс UNC становится вашим узким местом, и если он выходит из строя, все узлы выходят из строя.
2. Дисковый ввод-вывод и настройка сетевого взаимодействия могут быть проблемой. Это связано с количеством «Наблюдателей за файловой системой», которые могут быть открыты / поддержаны для удаленного содержимого. Эта проблема не является большой проблемой в БОЛЬШИНСТВЕ случаев, но может быть королевской PITA, когда это происходит.
3. Безопасность может быть проблемой, но обычно это то, с чем у вас возникают проблемы в начале настройки. Вы должны быть уверены, что правильно назначаете разрешения для учетной записи пользователя, чтобы она могла иметь полный доступ к общему ресурсу UNC.

Мое предположение относительно того, почему это "стандартная" рекомендация корпорации DotNetNuke, объясняется следующим. ПРИМЕЧАНИЕ: это ТОЛЬКО мои мнения.

1. Эта конфигурация обеспечивает «наименьшие» сложности, когда дело доходит до синхронизации контента в реальном времени. При использовании только одной файловой системы нет необходимости говорить о репликации и тому подобном.
2. Кэширование по умолчанию использует кеширование на основе файлов, при этом легко управлять одинаковым истечением срока действия системного кеша. Если воспроизвести, это не сработает.

Нет ничего плохого в использовании общего ресурса UNC. В предыдущей компании у нас были десятки веб-серверов, и все они использовали общие ресурсы UNC (а не DNN). Платных подписчиков было более 80 тысяч, из которых 10 тысяч использовали приложения каждый день. Это сработало очень хорошо.

Чтобы ответить на вопросы Митчела:

1.) Единственная точка отказа - это проблема, только если вы сделаете это проблемой. В различных решениях SAN / NAS имеется много возможностей резервирования.

2.) IO не будет проблемой для любого приличного SAN или NAS. У меня никогда не было проблем со наблюдателями файловой системы. DNN не использует их напрямую, и в том маловероятном случае, если встроенные наблюдатели ASP.Net создадут проблему, я, вероятно, отключу их.

3.) Я не считаю безопасность более серьезной проблемой, чем любое другое решение. Вы должны быть уверены, что контролируете доступ к своим файлам и устанавливаете разрешения соответствующим образом. С локальными дисками вы можете оставить разрешения более открытыми, чем в сети, но, вероятно, вам следует одинаково хорошо защитить и то, и другое. Существует дополнительный шаг настройки, связанный с использованием пути UNC. Дополнительные усилия по настройке безопасности будут незначительными по сравнению с неделями, если не месяцами усилий, затраченных на создание сайта, достойного веб-фермы.

Я полностью согласен с мнением Митчела о том, почему бы не использовать синхронизацию файлов.

Я знаю, что есть люди, которые запускают сайты DNN с синхронизацией файлов. Я не знаю никого, кому бы не приходилось решать проблемы, вызванные синхронизацией файлов. Лично я сомневаюсь, что обеспечение хорошей работы сайта с синхронизацией файлов дешевле, чем использование UNC в сети SAN, если посчитать трудозатраты на устранение причуд синхронизации файлов.