Привет! Меня зовут Максим Акимов, я являюсь руководителем команды разработки SharePoint.

В этой статье я бы хотел описать наш опыт работы с очень большой системой управления проектами, реализованной на SP, с какими ограничениями мы столкнулись и как добились "похудения" данной ИС.

Вводные

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

Суть проблемы

С ростом и развитием ИСУП’а он уперся в несколько ограничений вендора:

1. Рекомендуемое количество дочерних сайтов – 2000, в нашем случае более 3000.

2.  Рекомендуемы размер контентной базы данных – 200Гб, ИСУП вырос до ~ 4 Тб.

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

Сайты проектов создавались по 15 – 20 минут вместо минуты, на последних проектах прерывались рабочие процессы выдачи прав доступа, и все это приводило к огромному количеству ручного труда и работы с пользователями. Размер контентной БД, в свою очередь, повлек за собой неявные проблемы:

• Нет возможности Backup’а портала перед установкой обновления. Обновление проходит в технологическое окно, в рамках которого банально недостаточно времени для резервного копирования всего этого объема.

• Full-backup, который происходит по выходным, загружал CPU на SQL севере до 100%. Это могло длиться и 3, и 4 часа, и на такое поведение очевидно реагировал наш отдел мониторинга, что приводило к выходу в нерабочее время сотрудника.

Итого мы имеем:

1. Огромный портал, который превысил ряд ограничений SP и продолжает расти

2. Нагрузка на сервер SQL при full-backup’ е

3. Отпадающие по таймауту запросы от рабочих процессов и не только

4. Проблемы с производительностью

5. И, как вишенка на торте, большой риск потери информации с портала во время релиза, поскольку нет возможности произвести Backup здесь и сейчас в тех окно

Путь к здоровью портала

Этап первый – отрицание

Когда мы начали замечать рост проблем с порталом, мы провели аналитику с целью понять, имеют ли данные сбои общие корни. Все, в том числе и бизнес, старались не замечать масштаба проблемы и «лечили» симптомы вместо болезни.

Этап второй – гнев (негодование)

После того, как масштаб проблемы и ее суть стали понятны, у владельцев ИС возник вполне логичный вопрос: «Откуда взялась проблема?» со стороны пользователя, подобное поведение выглядит очень странным, ведь еще буквально вчера все было хорошо, и никто ничего не трогал.

В этот момент началось «дипломатическое» общение, в ходе которого мы провели ряд встреч с бизнесом, в рамках которых мы четко описали суть проблемы, причины ее возникновения, описали жизненный цикл крупных проектов и познакомили владельцев ИС с ограничениями вендора. Результатом общения стало то, что мы отложили текущий пул работ и бросили все силы для устранения технологического долга ИСУП.

Этап третий – торг

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

Для «идеального» сценария трудозатраты оказались не совместимы с реальностью, и в ходе общения с пользователями и владельцами ИС, был выбран тот необходимый пул работ, который позволит нам спасти ИСУП и при этом справиться с ним нашими имеющимися ресурсами.

Этап четвертый – депрессия

Тут стоит оговориться, что с «депрессией» в общем понимании в данном пункте нет ничего общего.

Речь о том, чтобы после всех переговоров, оценок и проработок плана мы осознали, что времени на реализацию проекта у нас X, и столько же времени до конца года, а поскольку эта работа проводилась в аккурат после "ковидного" периода, понимания, что будет в следующем году не было ни у кого, и перспективы не успеть в таком раскладе выглядели абсолютно не радужно.

Этап пятый – принятие

В этой части у нас самое сладкое, а именно – что же мы все-таки сделали для похудения?

План был такой:

1. Создать архив и переместить туда все завершенные проекты, также реализовать автоматизированный перенос для тех проектов, которые будут закрыты в будущем.
   Архив в данном случае – это отдельное семейство сайтов со своей контентной БД с активированным RBS (подробнее далее).
   На словах все просто, но стоит вспомнить, что портал в архиве не позволяет лишь удалять/изменять/создавать элементы, однако, все данные должны быть доступны для просмотра, а довольно большая визуальная часть завязана на корневом портале и запросах к нему различными js скриптами. Соответственно помимо переноса сайта (backup – restore) и корректировки доступов, также нужно подменить все ссылки, ведь коллекции сайтов разные. На этом этапе достаточно много сил и времени было потрачено на поиск мест, где на сайте проекта есть ссылки на корневой сайт ИСУП.

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

   

2. Архив мы создали и уменьшили объем основной контентной БД на ~ 200 Гб, но есть подвох… Общий объем хоть и стал меньше, но он по-прежнему больше 3 Тб, что все еще превышает ограничения SharePoint.
   Что же делать? Использовать Remote Blob storage!

   Remote Blob storage, далее RBS, позволяет приложениям, таким как SharePoint Server, хранить BLOB-объекты в расположении за пределами контентных баз данных.

   Это как раз наш вариант, поскольку основной объем ИСУП’а составляют различные файлы, однако, сама по себе активация RBS начнет класть отдельно от БД только новые файлы, те, что были до активации продолжают храниться в контентной базе.

   Это стало большой проблемой. Собственно, для того, чтобы изучить работу миграции RBS мы сделали бэкап продуктивной БД, перенесли ее на тест, запустили миграцию из стандартного функционала и … она работала 4 месяца, несколько раз прерывался и так и не закончил свою работу. Из этого опыта мы понимаем, что стандартный функционал миграции на наших объемах не жизнеспособен. Также за ним замечен еще один недостаток – нет никакой возможности отслеживать прогресс выполнения миграции, что на 3 Тб данных выглядит как гадание на картах вместо контролируемого процесса.

   Как с этим бороться? Если включенный RBS переносит вновь созданные файлы сразу в BLOB storage, то нам просто нужно заново загрузить все файлы на портал! И вот мы подошли к финальному штриху – мы реализовываем PowerShell скрипт, который позволяет точечно, начиная от конкретной папки и заканчивая всем Web’ом, пробегать по структуре, скачивать файлы, при этом сохраняя все их метаданные, удалять их, а затем загружать обратно и возвращать метаданные на место.

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

   Проект весит 500 Гб? Запускаем наш скрипт на папках проекта по отдельности и получаем результат в течение нескольких дней, видя прогресс переноса в RBS по каждой папке отдельно.

   Другой проект занимает 50 Гб? Запускаем скрипт сразу на весь сайт, и он достаточно быстро переносит все файлы в RBS.

   Оставшиеся проекты вместе занимают немногим больше 300 Гб? Запускаем скрипт сразу на всех, и в течение прогнозируемого времени все файлы оказываются в новом хранилище.

Финал

Какой итог всей проделанной работы?

Наш портал избавился от лишнего веса, и контентная база основного портала стала занимать ~ 200Гб.
Проблемы в работе рабочих процессов ушли, Backup SQL теперь не загружает сервер на 100%, новые сайты порталов теперь создаются почти мгновенно, а не по 15 минут, и появилась возможность делать бэкап без Blob’ов, что дает возможность более безопасно манипулировать данными в моменты релизов.

Спасибо за внимание!