Microsoft SharePoint 2012: Оптимизация работы SharePoint с RBS

Организации всех размеров используют Microsoft SharePoint в качестве репозитория и системы управления документами. В результате на SharePoint хранится большое количество документов, численность которых часто достигает миллионов.

SharePoint хранит все эти документы в базе данных SQL Server как большие двоичные объекты (BLOB). Как и другие реляционные базы данных, SQL Server не предназначен для хранения больших двоичных объектов в таких количествах. Это может создавать препятствия на различных уровнях, что снижает производительность SharePoint и делает администрирование баз данных очень сложным.

Для решения этой проблемы в SharePoint 2007 разработчики Microsoft реализовали основанную на технологии COM модель провайдера внешнего хранения больших двоичных объектов (External BLOB Storage, EBS). Технология EBS позволяет разместить большие двоичные объекты во внешних хранилищах и значительно уменьшить размер базы данных. Это решает проблему размера базы данных, но отсутствие «родного» провайдера .NET ограничивало производительность и не обеспечивало настоящей интеграции с SharePoint. Поэтому это решение нельзя считать полноценным.

В SharePoint 2010 и SQL Server 2008 R2 Microsoft выпустила «родной» интерфейс удаленного хранения BLOB (RBS) на основе .NET, который пришел на замену EBS. Механизм RBS также помогает значительно снизить размер базы данных SharePoint 2010 за счет переноса всех объектов BLOB из базы данных контента SharePoint на указанные пользователем внешние накопители. Заглушки и метаданные для этих больших двоичных объектов по-прежнему хранятся в базе данных контента. В результате SharePoint продолжает «думать», что эти большие двоичные объекты являются частью SharePoint и доступ к ним осуществляется по-прежнему. Пользователи не чувствуют никакой разницы, потому что все большие двоичные объекты по-прежнему логически являются частью базы контента.

В настоящее время Microsoft предоставляет базовую реализацию, которая называется RBS Filestream. Однако она достаточно базовая и не обеспечивает достаточной гибкости для серьезных пользователей SharePoint. Хотя этот провайдер выгружает большие двоичные объекты, он не позволяет задать фильтры, определяющие, какие большие двоичные объекты выгружать, а какие оставлять в базе данных. В результате приходится выгружать все большие двоичные объекты. Кроме того, нельзя указать место удаленного хранения больших двоичных объектов, а все BLOB-объекты размещаются только в локальном хранилище на компьютере с SQL Server. Нет также средств управления или мониторинга.

Если вы более или менее серьезный пользователь SharePoint, вам нужен больший контроль и гибкость обработки и хранения больших двоичных объектов. Есть некоторые довольно приличные реализации RBS сторонних разработчиков, которые прекрасно работают и решают проблему размера базы данных SharePoint. Необходимо обеспечить, чтобы используемая реализация сторонних разработчиков была на сто процентов совместима с .NET, а не лоскутным одеялом из компонентов Java и .NET, что может вызвать проблемы с совместимостью.

Одно из преимуществ модели провайдера RBS заключается в том, что она открыла SharePoint для сторонних производителей, чтобы предоставить больше возможностей по реализации RBS. Любая реализация провайдера RBS позволяет задавать место хранения больших двоичных объектов. Этот элемент управления можно использовать для предоставления пользователям SharePoint больше возможностей по управлению BLOB-объектами помимо уменьшения размера базы данных и повышения производительности. В этом отношении есть четыре основных направления усовершенствования SharePoint:

• Снижение затрат на хранение данных за счет оргиназации многоуровневого хранения BLOB
• Архивирование и хранение больших двоичных объектов в соответствии с требованиями законодательства и регулирующих органов.
• Привязка к SharePoint документов, внешних по отошению к SharePoint
• Реализация кеширования BLOB в памяти.

Многоуровневое хранение данных

Одним из основных преимуществ RBS является возможность размещения больших двоичных объектов на нескольких уровнях хранения, вместо хранения в одном месте. Это позволяет значительно сократить затраты на хранение. В отсутствие RBS все двоичные объекты хранятся в базе данных SQL Server. Даже RBS Filestream использует SQL Server для хранения больших двоичных объектов. Это единое место хранения, как правило, требует наличия довольно дорогой подсистемы хранения, например массива SAN или NAS.

Большие двоичные объекты обычно составляют около 90% всех данных в SharePoint, и одновременный доступ ко всем им требуется редко. Поэтому хранение всех больших двоичных объектов в дорогостоящих SAN- и NAS-массивах, когда доступ к этим объектам происходит нечасто, обходится недешево, а устройства хранения используются неэффективно.

Более разумной стратегией было бы хранить на дорогих носителях только новые и активные документы (BLOB), потому что пользователи должны получать доступ к таким документам чаще и быстрее. А остальные, более старые и не так часто используемые двоичные объекты можно хранить на более дешевых уровнях хранения. Это означает, что не потребуется большое количество дорогих устройств хранения. Можно сократить количество дорогих дисковых устройств и использовать более дешевые хранилища, чтобы переложить на них работу по хранению.

Одним из примеров хранения на различных уровнях является случай, когда имеются новые активные документы, хранящиеся на дорогом массиве SAN. Кроме того, есть обычный файловый сервер в качестве второго уровня и облачная система для хранения данных на третьем уровне. Массив SAN является самым быстрым и самым дорогим, облако является самым медленным и самым дешевым, а файловый сервер находится где-то между ними. В результате общая стоимость хранения снижается. В настоящее время 80-85% имеющихся двоичных объектов больше не хранятся на дорогих устройствах хранения SAN. Вам не нужен частый доступ и, следовательно, не требуется высокая доступность, высокопроизводительная система хранения SAN.

Теперь, когда есть многоуровневое хранилище, возникает следующий вопрос: как задать распределение больших двоичных объектов по уровням хранениях. Это определяется для нескольких уровней хранения на основе логически обоснованных критериев. Место размещения BLOB-объекта определяется, когда он впервые создается (или при первичной выгрузке из базы данных SQL Server). После этого BLOB-объекты периодически проверяются, также проверяется и возраст каждого и как часто он используется.

Некоторые провайдеры RBS предоставляют возможность использовать BLOB-фильтры. Обычно на уровне хранения определяется один или несколько BLOB-фильтров. Это означает, что на уровне хранения могут храниться только BLOB-объекты, удовлетворяющие условиям фильтров. Остальные большие двоичные объекты должны анализироваться на других уровнях хранения и храниться там, где они удовлетворяют условиям BLOB-фильтров.

Если BLOB не соответствует ни одному фильтру хранения ни на каком уровне, его можно оставить в базе данных SQL Server. BLOB-фильтры обычно включают название документа, размер, возраст, автора и даже тип содержимого. В фильтрах можно использовать специально добавленные пользовательские мета-теги или тип файла (например, авторы, исполнители, альбомы и т. д.).

Некоторые провайдеры RBS позволяют изменять фильтры на устройствах хранения BLOB. При этом BLOB-объекты будут автоматически пересортироваться и перемещаться с одного уровня хранения на другой на основе новых BLOB-фильтров. Другие провайдеры RBS только оценивают значение фильтров BLOB в момент их создания.

Для периодической проверки в части провайдеров RBS используется архивирование на основе возраста, версии или характера использования. Работающая на SharePoint в фоновом режиме задача проверяет все объекты BLOB по возрасту, версии и способу использования. Хотя возраст и информация о версии хранятся в содержимом базе данных SharePoint, сведения о характере использования сохраняются провайдером RBS в отдельных таблицах или базах данных.

Если любой старый BLOB-объект или документ вдруг становится популярным и к нему часто обращаются, некоторые (не все) провайдеры RBS умеют автоматически перемещать его на более дорогие устройства хранения данных. Таким образом, потери производительности исключаются. Чем дороже устройство хранения, тем меньше его время отклика, и наоборот: как правило, чем дешевле хранилище, тем больше время отклика.

Архивирование больших двоичных объектов

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

Архивирование BLOB-объектов для удовлетворения требований законодательства гарантирует, что они не будут случайно удалены из SharePoint каким-то пользователем. Многие провайдеры RBS не поддерживают архивирование в смысле резервного копированиня хранимых больших двоичных объектов. Они используют слово «архив» для обозначения перемещения объектов BLOB с одного уровня хранения на другой. Но у некоторых провайдеров RBS действительно есть функции резервного копирования BLOB.

Часто бывает так, что документы нужно хранить в течение определенного периода времени — по юридическим причинам или если этого требует политика компания. Например, во многих отраслях договоры и соглашения хранят пять лет. Такое соблюдение установленных правил часто встречается в финансовых, страховых и других подобных отраслях. Однако подобные требования есть практически к любой компании.

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

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

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

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

Библиотеки документов, не хранящихся в SharePoint

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

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

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

Пользователи SharePoint хотели бы иметь доступ к таким документам через SharePoint. Альтернативный вариант заключается в том, чтобы пользователи SharePoint входили в каждую систему управления документооборотом отдельно, чтобы искать документы, открывать их для редактирования и «самостоятельно» регистрировать их поступление и удаление. Это, как минимум, неудобно.

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

Провайдеры RBS позволяют задавать местоположение этих внешних библиотек документов. Они перечисляют эти документы и создают мета-данные для каждого документа в SharePoint. Провайдеры RBS затем «заставляют» SharePoint полагать, что эти находящиеся во внешнем хранилище документы находятся на сервере SharePoint.

Когда сборщик данных SharePoint индексирует все документы на основе ключевых слов, он также полагает, что эти документы являются обычными документами SharePoint (пока речь идет о метаданных). Именно поэтому сборщик может индексировать их, как и все другие документы SharePoint.

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

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

Хороший провайдер RBS позволяет реализовать хранение документов, не относящихся к SharePoint на подключаемых пользовательских носителях. Если уже имеется пользовательская система управления документооборотом, которая хранит все документы в базе данных Oracle, и вы знаете структуру этой базы данных, можно реализовать собственный подключаемый модуль для этого внешнего накопителя.

Реализация пользовательских подключаемых модулей обычно предусматривает написание кода .NET и регистрации полученной сборки .NET на веб-серверах (WFE) серверов SharePoint. Такой подключаемый модуль дает возможность SharePoint просматривать хранилища, брать документы на редактирование и сохранять их в хранилище, а также извлекать документы для чтения.

Кеширование BLOB-объектов в оперативной памяти

Провайдеры RBS могут также включать кеширование BLOB в памяти. Всякий раз, когда большие двоичные объекты извлекаются из базы контента, базы данных SQL Server или даже внешнего хранилища больших двоичных объектов, они кешируются в кеш-памяти WFE сервера. В следующий раз, когда пользователю нужно получить тот же документ, он может получить его из кеш-памяти. Это во много раз быстрее, чем переходить в BLOB-хранилище. Кеширование обеспечивают провайдеры RBS, которые управляют BLOB-объектами.

При наличии подключаемого модуля кеширования в памяти, можно кешировать большие двоичные объекты, списки SharePoint и состояние просмотра, а также состояние сеанса ASP.NET, которое иногда используется SharePoint. Кеширование списков и BLOB существенно сокращает время отклика, потому что SharePoint не нужно обращаться к базе данных и хранилищу. Кеширование состояния просмотра (ViewState) снижает объем данных, возвращаемых WFE-серверами вашему браузеру. Это снижает потребность в высокой пропускной способности сети, а также сокращает время отклика SharePoint, особенно если пользователи получают доступ к SharePoint по WAN-сети. Кеширование состояния сеанса позволяет копировать состояние сессии и предотвратить потерю данных, в дополнение к повышению производительности и масштабируемости.

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

SharePoint чрезвычайно ценная платформа. Она не идеальна, но многообщеающа. Механизм RBS был первоначально предназначен только для уменьшения размера базы данных и повышения производительности SharePoint, но оказался пригодным для решения многих других проблем.