Оптимизация прикладных приложений SharePoint

Вопросы, предлагаемые на экзамене специалистам по системе SharePoint 2016, распределяются по целому ряду разделов. Напомню, что в данной серии статей мы рассматриваем следующие темы:

• проектирование инфраструктуры SharePoint;
• оптимизация прикладных приложений SharePoint;
• прикладные службы;
• оптимизация и мониторинг.

В этой статье речь пойдет о втором пункте нашего списка — об оптимизации прикладных приложений SharePoint. Кроме того, вам нужно будет освежить свои знания в следующих областях:

• создание и обслуживание коллекций сайтов;
• планирование решений, обеспечивающих высокую доступность приложений SharePoint и восстановление данных в случае аварийного сбоя;
• планирование операций резервного копирования и восстановления;
• планирование и настройка общедоступных приложений;
• планирование и настройка прикладных приложений системы управления веб-содержимым Web Content Management (WCM);
• планирование и настройка прикладных приложений системы управления информационным содержимым предприятия Enterprise Content Management (ECM).

Ниже приведен ряд важных ссылок на материалы по проблемам, которые выходят за рамки данной статьи.

OneDrive for Business в версии SharePoint Server 2016:

• https://technet.microsoft.com/en-us/library/dn167720 (v=office.16).aspx
• https://technet.microsoft.com/en-us/library/dn232145 (v=office.16).aspx

Сайты My Sytes для SharePoint Server 2016:

• https://technet.microsoft.com/en-us/library/ff382643 (v=office.16).aspx
• https://technet.microsoft.com/en-us/library/cc262500 (v=office.16).aspx

Предотвращение потери данных в SharePoint Server 2016:

• https://support.office.com/en-us/article/Overview-of-data-loss-prevention-in-SharePoint-Server-2016-80f907bb-b944-448d-b83d-8fec4abcc24c
• https://support.office.com/en-us/article/Create-a-DLP-query-in-SharePoint-Server-2016-c0bed52d-d32b-4870-bcce-ed649c7371a3
• https://blogs.msdn.microsoft.com/mvpawardprogram/2016/01/13/data-loss-prevention-dlp-in-sharepoint-2016-and-sharepoint-online/

После того как вы спроектировали инфраструктуру SharePoint, начинается следующий этап работы: необходимо настроить службы и компоненты таким образом, чтобы обеспечить эффективное использование ресурсов. В этой статье наше внимание будет сосредоточено на обеспечении высокой доступности системы SharePoint. Эта задача может оказаться сложной: она касается не только служб, используемых приложениями SharePoint, и их доступности, но и доступа конечных пользователей и возможности работы с сайтом.

Прежде всего, давайте определимся с тем, что мы понимаем под словами «высокая доступность». В данном случае речь идет не о восстановлении после аварийного сбоя, хотя такие ситуации вписываются в рассматриваемую область. Мы говорим о достижении такого положения, когда все компоненты функционируют на протяжении всего времени (или максимально возможного времени) и обеспечивают для конечных пользователей максимально возможную производительность в соответствии с их потребностями. Термин «высокая доступность» обычно используется для описания способности системы продолжать функционирование и предоставлять ресурсы своим пользователям в ситуации, когда имеет место сбой в одной или нескольких категориях дефектной области: аппаратные средства, программное обеспечение или приложение. Уровень доступности выражается как процентная доля времени, в течение которого система продолжает оставаться в исправном состоянии и выполняет рабочие функции. В каждой организации признается необходимым свой уровень доступности. И хотя этот уровень может изменяться от одного подразделения к другому, соглашение об уровне обслуживания является единым для всей организации. С точки зрения пользователей, ферма SharePoint считается доступной, когда пользователи могут обращаться к ней и задействовать все функции и службы, необходимые им для работы.

При проектировании и создании обладающей высокой доступностью фермы SharePoint цель разработчика состоит в следующем:

1. Структура фермы обеспечивает сокращение числа возможных точек отказа.
2. События аварийного переключения осуществляются плавно и в минимальной степени влияют на работу пользователей.
3. Ферма не прекращает работу, а продолжает функционировать со сниженной производительностью.
4. Ферма сохраняет работоспособность.

В сущности, доступность SharePoint первоначально сводится к логической схеме, избранной для физической или виртуальной машины, которая будет применяться. К примеру, при использовании виртуальной среды принцип высокой доступности предполагает, что не все виртуальные машины SharePoint размещаются на одном и том же физическом хосте (рисунок 1).

Рисунок 1. Ферма, развернутая в физической среде

При использовании физических систем применяется та же схема: для каждой роли SharePoint выделяется по меньшей мере два сервера, а также сервер SQL, реализующий технологию, которая позволяет в случае аварийного переключения разделять узлы (рисунок 2).

Рисунок 2. Ферма, развернутая в виртуальной среде

Кроме того, если наша цель состоит в том, чтобы добиться высокой доступности, мы должны держать в поле зрения каждую службу, размещенную внутри фермы SharePoint. К примеру, в процессе аварийного переключения особого внимания требует компонент кэша Distributed Cache, а компонент SharePoint Workflow следует дополнить пакетом Workflow Manager 1.0 Cumulative Update 3; эти обстоятельства должны учитываться при разработке общей структуры.

Хотя служебные приложения могут выполняться на нескольких компьютерах, а именно такой вариант и рекомендует Microsoft, при размещении этих приложений в структурах, обеспечивающих высокий уровень доступности, некоторые из них устанавливаются особым образом. Характерный пример — приложение User Profile. Знание таких особенностей поможет вам в создании эффективных решений с высокой степенью доступности.

В процессе создания подобных решений хорошо зарекомендовал себя охватывающий все компоненты принцип «расширяющейся фермы» (Stretched Farm). Он реализуется на всех уровнях структуры, от баз данных до трафика конечного пользователя с балансировкой нагрузки. Принцип расширяющейся фермы предполагает размещение серверов, обслуживающих SharePoint, SQL и другие компоненты, в различных центрах обработки данных. Однако реализовать этот принцип вы сможете лишь в том случае, если ваша среда удовлетворяет следующим требованиям:

1. Задержка в передаче данных внутри фермы отличается высокой стабильностью и составляет менее 1 миллисекунды (в одну сторону) на протяжении 99,9% времени в течение десятиминутного периода (задержка внутри фермы обычно определяется как задержка в ходе обмена данными между внешними веб-серверами и серверами баз данных).
2. Пропускная способность должна составлять по меньшей мере 1 Гбайт/с.

Хотя в случае невыполнения названных условий система и будет работать, в конце концов вы столкнетесь с потенциальными ошибками и убедитесь, что ваша среда не полностью обеспечивает решение поставленных задач.

Логическая основа структуры достаточно проста: система SharePoint устанавливается по стандартной схеме, серверы в соответствии с необходимостью наделяются ролями MinRole и устанавливаются не в одном центре обработки данных, а в двух. При этом мы не создаем, что называется, старое доброе средство аварийного переключения. Скорее мы формируем среду, в которой трафик можно с легкостью направлять между сайтами как в одну, так и в другую сторону.

Схема на рисунке 3, подготовленная специалистами Microsoft (https://i-technet.sec.s-msft.com/dynimg/IC654215.gif), отображает простую структуру среды.

Рисунок 3. Схема «расширяющейся фермы»

В каждом центре обработки данных может быть размещено большее количество серверов; это зависит от того, сколько серверов, служб и компонентов вам необходимо. Обратите внимание на то, что узловым элементом этой конструкции является не только комбинация SQL Always On/Mirroring, но и сочетание компонентов DNS/Load Balancer, управляющее запросами пользователей. Преимущество такой организации состоит в том, что содержимое размещается везде. Но еще важнее другое: когда возникает необходимость развертывания какого-либо компонента, например пакета Solution Package (WSP), он автоматически отправляется в принудительном порядке на все серверы вне зависимости от того, в каком центре обработки данных они располагаются.

Однако самым важным элементом этой схемы в действительности является инфраструктура баз данных. Ключевым элементом здесь становится формирование такого решения, как Mirroring, или лучшего варианта групп доступности Availability Groups (https://technet.microsoft.com/en-us/library/jj841106(v=office.16).aspx).

Более подробную информацию о средствах высокой доступности, а также о средствах восстановления после сбоя можно найти в документах корпорации Microsoft, перечисленных во врезке «Дополнительная информация».