Как в случае с любой версией SharePoint, существуют изменения, которые неизбежно отражаются на общей логике проектирования фермы. До появления SharePoint 2016 разработчикам предоставлялись конкретные рекомендации в рамках так называемой «традиционной» модели, которая основывалась на простом трехуровневом подходе, объединяющем серверы базы данных, приложений и Web (см. рисунок 1).
Рисунок 1. Простой трехуровневый подход |
Это достаточно удобный подход, с помощью которого очень просто построить ферму SharePoint, однако ему свойственны ограничения выбора для каждого сервера. С точки зрения информационной безопасности это означало, что уязвимая поверхность каждого сервера оказывалась гораздо больше, чем могла бы быть. Благодаря последующим версиям, выпущенным Microsoft, мы получили «упрощенный» подход, который предусматривает увеличение базового числа серверов путем выделения роли, именуемой распределенным кэшем, и наличие в SharePoint внутренней подсистемы балансировки нагрузки, обеспечивающей при необходимости передачу трафика между всеми серверами в соответствии с назначениями. Поэтому трафик приложения-службы всегда распределяется за счет выбора оптимального узла, с которого к нему можно обратиться (см. рисунок 2).
Рисунок 2. Добавление распределенного кэша |
В версии SharePoint 2016 появились так называемые мини-роли MinRole, которые оказывают огромное влияние на число серверов, необходимых для работы фермы. Для типовой среды SharePoint 2016 теперь требуется четыре сервера в ферме, если используется роль MinRole. Это очень похоже на другие топологии, привычные в SharePoint 2013. Основное различие в том, что на серверах включены только функции и компоненты, необходимые для конкретной роли (см. рисунок 3).
Рисунок 3. Типовая среда SharePoint 2016 |
Одно из основных новшеств SharePoint 2016 — возможность горизонтального масштабирования каждого сервера, поэтому ферма с высокой доступностью будет выглядеть так, как показано на рисунке 4.
Рисунок 4. Ферма с высокой доступностью |
Как можно заметить, число серверов удвоилось по сравнению с менее крупной фермой, но доступность каждого компонента повысилась. Эта логическая структура позволяет комбинировать роли необходимым образом, сочетая все модели MinRole. Теперь не обязательно следовать подходу MinRole, можно выбрать особую установку, позволяющую следовать старому стилю проектирования.
При необходимости в целях оптимизации структуры можно сочетать серверы MinRole с настраиваемыми серверами (Custom). Я предпочитаю хранить верность структуре MinRole, поскольку в данном случае мне известно, что на всех серверах активны только роли и службы, назначенные мною. Кроме того, с помощью функций соответствия можно увидеть, если кто-нибудь включит или изменит какие-либо параметры среды, нарушив характеристики соответствия серверов.
Основную логику такого типа архитектуры можно свести к следующим преимуществам:
- Предопределенные роли.
- Подсистема балансировки нагрузки приложения-службы ориентирована на локальный экземпляр.
- Упрощение развертывания.
- Высокая масштабируемость фермы.
- Уменьшение количества ошибок при настройке.
- Повышенные производительность и надежность.
- Прогнозируемое планирование ресурсов.
- Автоматическая настройка параметров.
В целом такой подход позволяет улучшить структуру, упростить поддержку и получить более продуманное решение.
Дополнительные сведения можно получить, изучив официальные диаграммы Microsoft для SharePoint 2016 по адресу: https://docs.com/officeitpro/2973/microsoft-sharepoint-architectural-models.