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

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

8 голосов
/ 14 июля 2011

В прошлом меня учили, что неразумно запускать веб-приложение из общего ресурса UNC.Причины, которые я помню, это проблемы безопасности, прав и авторизации, а также производительность.Однако в документации DotNetNuke говорится: :

Конфигурация веб-фермы, которую изначально поддерживает DotNetNuke, включает два или более интерфейсных веб-сервера («веб-головы»), чей веб-сайт IISкорневые каталоги сопоставляются с общим ресурсом UNC на удаленном файловом сервере.Общий ресурс UNC содержит исходный код приложения, а также любой статический контент для отдельных сайтов.

Почему-то это звучит как конфигурация плохого человека, и я чувствую, что открываю ящик потенциального Пандоры.Разумно ли следовать предложению DotNetNuke Corp здесь?

Ответы [ 2 ]

5 голосов
/ 15 июля 2011

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

Чтобы обратиться к точкам Митчела:

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

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

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

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

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

4 голосов
/ 14 июля 2011

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

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

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

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