В одной из предыдущих статей я рассказывал об ограничениях масштабируемости содержимого сайтов и рекомендациях, в которые компания Microsoft позднее внесла поправки. Я обещал, что мы всерьез возьмемся за дело и будем обсуждать перемещение объектов BLOB во внешние хранилища, поскольку вполне вероятно, что, если потребуется обеспечить поддержку больших баз данных контента, вы, скорее всего, будете рассматривать перенос объектов BLOB как один из этапов работы по оптимизации механизмов хранения.
Как мы уже знаем, по умолчанию система SharePoint сохраняет в базе данных контента все данные сайтов, в том числе большие двоичные объекты binary large objects (BLOB), представляющие собой неструктурированные данные, такие как документы в библиотеке документов и вложения в элементах списка. В базе данных контента на сервере SQL Server объекты BLOB хранятся в таблицах, состоящих из метаданных о документах и элементах списка. Исходя из этого понятно, что двоичные объекты влияют на производительность. Система SQL Server как продукт оптимизирована для работы с небольшими (8 Кбайт или меньше) структурированными данными и работает лучше всего при использовании шаблонов доступа, предназначенных для такого типа данных. При перемещении объектов BLOB в отдельные таблицы производительность системы SharePoint повышается, поскольку увеличивается производительность SQL Server.
У нас есть возможность перенести объекты BLOB еще на уровень дальше от баз SQL Server, и, возможно, от дорогого хранилища первого уровня, которое во многих организациях используется системой SQL Server, в хранилища других типов, включая NAS, общие папки или «облачные» хранилища. Это можно сделать с помощью внешнего хранилища объектов BLOB, External BLOB Storage (EBS) — набора программных интерфейсов, введенных в систему SharePoint 2007 (MOSS 2007/WSS v3) с пакетом обновления 1, или с использованием удаленного хранилища объектов BLOB, Remote BLOB Store (RBS) — платформы и набора программных интерфейсов, уже встроенных в систему SQL Server, доступных из системы SharePoint посредством версии RBS из пакета Feature Pack для системы SQL Server 2008 R2. Последний также может быть установлен в системе SQL Server 2008 SP1. Оба набора, EBS и RBS, поддерживаются системой SharePoint 2010 (версиями Foundation и Server) и всеми редакциями SQL Server (включая Express) с различными оговорками и ограничениями.
Наборы EBS и RBS требуют разработать или приобрести код (так называемый «провайдер» для RBS), который реализует корректные API-интерфейсы для платформы хранения. Установщик RBS включает в себя «провайдер», называемый FILESTREAM, который может использоваться для перемещения объектов BLOB в локальную файловую систему сервера SQL Server (которая может включать в себя подключенные тома SAN, так как они представлены в виде локальных томов). Компания Microsoft недавно объявила о поддержке томов NAS, в которых задержки и время доступа к первому байту time-to-first-byte (TTFB) находятся в пределах нормы (20 мс TTFB). Провайдер FILESTREAM встраивается в систему SQL Server. Сторонние RBS (и EBS) «провайдеры» могут перемещать объекты в более широком спектре платформ хранения данных и, как правило, превосходят «провайдер» FILESTREAM по характеристикам. Некоторые сторонние «провайдеры» даже предоставляются бесплатно, и, по-моему, очевидно, что на них нужно обратить внимание, если вы собираетесь перемещать объекты BLOB.
Но вопрос в том, стоит ли перемещать объекты BLOB во внешние хранилища? В Интернете очень много сведений по данной теме. Вместо того чтобы пересказывать их здесь, я собираюсь обобщить и инкапсулировать самые важные вопросы, а также выделить несколько основных положений, которые, я считаю, незаслуженно остаются незамеченными или искажаются в обсуждениях.
. Нужно учитывать множество факторов и очень тщательно планировать отдельное хранение объектов BLOB. Пожалуйста, имейте в виду, что большая часть преимуществ отдельного хранения объясняется недостатками традиционного подхода к хранению, и, наоборот, недостатки отдельного хранения могут быть преимуществами хранения объектов BLOB в базе данных контента. А теперь вкратце рассмотрим вопросы, связанные с отдельным хранением.
Снижение затрат на хранение
Объекты BLOB могут быть перемещены из дорогих, высокопроизводительных систем хранения данных SQL Server на менее дорогостоящие платформы хранения данных. Это простой аргумент для понимания и легкого расчета окупаемости инвестиций. Я знаком с несколькими клиентами, у которых суммы экономии на дисковом пространстве в год были представлены семизначными числами! Не забывайте и о влиянии данного подхода на работу с журналами транзакций при расчете экономии за счет смены хранилища.
Более высокая производительность доступа к файлам
Это преимущество достаточно хорошо обосновано. Объекты BLOB повышают нагрузку на процессор и оперативную память сервера SQL Server каждый раз при выполнении операции чтения или записи. Причем операции записи особенно уязвимы, поскольку объект BLOB записывается дважды — сначала в журнал транзакций для обеспечения согласованности транзакций, а затем и в соответствующую таблицу в базе данных содержимого SQL Server. После анализа большого объема данных стало очевидно, что операции с файлами размером более 1 Мбайт работают лучше (чтение и запись), если объекты BLOB находятся во внешних хранилищах, а очень маленькие файлы (менее 256 Кбайт), как правило, обрабатываются быстрее в базе данных контента. Однако при подсчете производительности учитывается множество различных факторов, и наиболее важными являются модели доступа, а также характеристики хранилищ и провайдеров RBS.
Более высокая производительность доступа ко всему содержимому на сервере SQL Server
На мой взгляд, об этом очень мало говорят: при отдельном хранении даже небольших объектов BLOB (менее 256 Кбайт) вы можете повысить производительность системы SharePoint во всех задачах. Коротко говоря, если у вас есть только один пользователь, то данное утверждение не работает. Но если посмотреть на реальную рабочую нагрузку, когда несколько пользователей обращаются к службе SQL Server и некоторые из этих пользователей выполняют чтение и запись объектов BLOB (даже небольших), совокупное воздействие снижает производительность для всех пользователей — даже для тех, кто обращается к данным, которые не имеют ничего общего с объектами BLOB (например, при просмотре списков). Объекты BLOB, которые задействуются несколькими пользователями, «притормаживают» доступ к ресурсам SQL Server для всех остальных. У клиентов я наблюдал значительное увеличение производительности при решении любых задач. Компания Microsoft опубликовала некоторые результаты тестов, которые подтверждают это наблюдение, и в течение ближайших недель вы увидите результаты тестов, опубликованные в Интернете, которые позволят определить количественные показатели повышения производительности. Но, поверьте мне, разница есть. Я уже подчеркивал, что есть нюансы и что требуется тщательное планирование, но использование отдельного хранения потенциально может дать большой выигрыш в производительности системы SharePoint в большинстве реальных сценариев рабочих нагрузок.
Доступ к важным функциям платформы хранения
Другим преимуществом отдельного хранения объектов BLOB, которому не уделяют должного внимания, является возможность использования функций применяемой платформы хранения. Даже при работе с «провайдером» FILESTREAM вы можете использовать встроенные механизмы файловой системы NTFS для сжатия и шифрования файлов. Другие платформы хранения данных предоставляют функции устранения дублирования, дифференциального сжатия, моментальных снимков и другие механизмы, применяемые для снижения занимаемого дискового пространства и более эффективного управления хранением.
Эффективная реструктуризация содержания
После переноса в отдельное хранилище объектов BLOB процесс реструктуризации контента — перемещение содержимого между сайтами, семействами сайтов и даже веб-приложениями — становится проще и выполняется быстрее. Некоторые из задач реструктуризации можно решить с помощью усовершенствованной команды Move-SPSite, входящей в состав системы SharePoint 2010 SP1. Для решения других задач потребуются сторонние утилиты, но суть в том, что вы можете перемещать метаданные базы SQL Server, сохраняя «указатели» на объекты BLOB неизменными, и нет необходимости на самом деле перемещать объекты BLOB.
Управление платформой хранения
Один из основных недостатков отдельного хранения объектов BLOB заключается в том, что ваш контент становится «разделенным». Теперь вам придется управлять двумя платформами — базами данных SQL Server и хранилищем объектов BLOB. Вы должны быть готовы взять на себя администрирование, внесение исправлений, планирование окон под обслуживание, мониторинг, аудит и все мероприятия, связанные с обслуживанием хранилищ. Среди наиболее важных операций хотелось бы выделить восстановление базы данных и элементов, аварийное восстановление и обеспечение высокой доступности — эти моменты настолько важны, что их стоит рассмотреть отдельно.
Резервное копирование и восстановление баз данных содержимого и элементов
Немало споров вызывают вопросы резервного копирования и восстановления содержимого после перемещения объектов BLOB, и все сводится к тому, что вы должны планировать резервное копирование и восстановление с учетом отдельного хранения, но это далеко не так сложно, как думают некоторые. Я еще напишу об этом подробнее, но в целом при наличии правильных технологий и процессов вы сможете разработать решение, которое будет соответствовать вашим соглашениям об уровне обслуживания (SLA). Опять-таки, определенные платформы хранения предоставляют возможности (в частности, резервное копирование и восстановление на основе снимков), незаменимые в очень объемных сценариях, а некоторые инструменты сторонних производителей позволяют обеспечить выполнение соглашений SLA менее чем за две минуты!
Восстановление после аварий и высокая доступность
Если объекты BLOB хранятся в базе данных контента SQL Server, использование встроенных механизмов кластеризации и зеркального отображения является одним из решений, обеспечивающих высокую доступность и возможность аварийного восстановления. При использовании отдельного хранения объектов BLOB необходимо разработать решение, отвечающее требованиям восстановления и отказоустойчивости.
Обязательно ознакомьтесь с содержанием следующих ресурсов:
- Capacity support and guidance changes, announced on the SharePoint Team blog: Data Storage Changes for SharePoint 2010.
- The details on TechNet: SharePoint Server 2010 capacity management: Software boundaries and limits.
- Bill Baer’s white paper: Managing Multi-Terabyte Content Databases with Microsoft SharePoint 2010.
- SQL Server RBS Performance with SharePoint Server 2010 and StorSimple Storage Solution.
А в блогах можно найти дополнительную информацию:
- Benjamin Athawes: Content DB sizing support in SharePoint 2010 SP1: the 50,000 ft view.
- Wictor Wilen: The SharePoint 2010 4 TB content database limit fine prints — just a warning!
- Dave Coleman: SharePoint ContentDB Guidance: Too many shades of gray along with a little brown.
- Chris Mullendore (MS PFE): SharePoint 2010 RBS Benefits/Trade-offs.
- Russ Houberg: New Content Database and RBS Sizing Guidance.
Хранилища RBS критикуют, потому что это сложное решение (более сложное, чем использование одной базы данных контента на сервере SQL Server), но мой опыт показывает, что отдельное хранение объектов BLOB (externalization) подходит для большинства ключевых сценариев, в частности при переносе объектов из общих файловых ресурсов, и если использование данного механизма тщательно продумано, оно может принести «большую победу». Пожалуйста, помните, что, хотя компания Microsoft сейчас подняла планку качества поддержки — теперь будет поддерживаться более широкое множество сценариев работы с контентом, — вы должны иметь полное представление обо всех требованиях, уязвимых местах и архитектурных аспектах.
Дэн Холм (danh@intelliem.com) — директор консалтинговой службы Intelliem, организующей консультации для предприятий, внедряющих SharePoint, Office, Windows и Active Directory