Удивительное дело эти технологии. Порой их применение дает невероятный, ошеломляющий эффект. Но через какое-то время они входят в нашу повседневную жизнь, и на них просто перестаешь обращать внимание. Я очень хорошо помню, как познакомился с системой RAID 5. Мой коллега извлек тогда накопитель из функционирующего сервера… и система продолжала работать! Она работала, и я смотрел на нее как громом пораженный. Должен сказать, что я счастливый человек — работаю в сфере технологий, и время от времени мне доводится переживать такие моменты, когда кроме «Вот это да-а-а!» ничего и не скажешь. Эти моменты отчасти объясняют мою увлеченность делом, которым я занимаюсь. Так вот, сети хранения данных Storage Area Networks (SAN) — еще один образчик неизъяснимой магии технологий. Эти сети дают нам возможность сосредоточить средства хранения данных в централизованных хранилищах и затем предоставлять их отдельным серверам по мере необходимости. В публикуемой ниже статье я расскажу о способах грамотного и надежного использования сетей SAN в средах Microsoft SharePoint. Исходя из того что продукты SharePoint функционируют на базе сложной инфраструктуры, я затрону и вопросы применения сетей SAN в сочетании со вспомогательными технологиями, такими как Microsoft SQL Server и хосты виртуализации. Вы получите наглядное представление о том, как сети хранения данных взаимодействуют с продуктами SharePoint и поддерживающими их решениями, а также о том, как наилучшим образом использовать данную технологию в корпоративных сетях.

Кое-что об основах SAN

На базовом, физическом уровне сеть хранения данных SAN представляет собой контейнер размером с холодильник, заполненный жесткими дисками. Повсюду мигают индикаторы, и один лишь их вид вводит в состояние умиротворения. Эти диски можно использовать в бесконечном числе разнообразных комбинаций, включая все уровни RAID, о которых нам доводилось слышать, а также парочку сочетаний, о которых мы понятия не имели. Эти комбинации — они называются номерами логических устройств logical unit numbers (LUN) — воспринимаются серверами как локальные тома хранения, да и выглядят именно так. Подобный подход обеспечивает множество преимуществ. Он позволяет централизовать средства хранения данных, облегчая задачу получения моментальных снимков сведений об использовании и информации о потребностях. Кроме того, этот подход расширяет наши возможности: теперь мы можем наращивать дисковое пространство серверов, «не перетасовывая» накопители RAID всякий раз, когда возникает необходимость в расширении объема дисковой памяти. Наряду с этим сети хранения данных обеспечивают дополнительные возможности восстановления после сбоя. Почти все сети SAN позволяют осуществлять «зеркальное» дублирование накопителей внутри такой сети, при этом многие предусматривают вариант с формированием зеркальных копий на накопителях других SAN. В ряде случаев хранилища SAN могут функционировать с большей производительностью, нежели системы хранения с прямым подключением, которые нередко поставляются с сервером. Устройства SAN обладают широчайшими возможностями настройки; как правило, кэш таких систем имеет большой объем, что часто позволяет добиваться весьма высокого быстродействия. Здесь уместно отметить, что обеспечение высокой производительности порой требует определенных усилий. Для многих из нас сети хранения данных представляются некими волшебными ларцами, которые открывают перед пользователем кладовые памяти и гарантируют неограниченное быстродействие. Мы исходим из того, что эти сети сконфигурированы корректно и будут работать эффективно. Но подобные предположения верны не всегда. Все эти массивы жестких дисков систем SAN сами по себе не настраиваются. Кто-то должен открыть дверцу шкафа и определить, как наилучшим образом сгруппировать эти диски для работы с приложением, которое они будут обслуживать. Файловые серверы вполне удовлетворятся массивом RAID уровня 5; журналы транзакций SQL Server лучше всего функционируют с массивом, обеспечивающим «зеркальное» дублирование, или с массивом RAID уровня 1. Но из того, что мы работаем с системой SQL Server, отнюдь не следует, что LUN, используемый нами для журналов транзакций, должен быть построен по схеме RAID 1. Возможно, нам приходится иметь дело с различными уровнями одного и того же типа приложений. Скажем, один экземпляр SQL Server содержит базы данных для приложения, которому требуется высокое быстродействие, тогда как другой экземпляр может содержать базы данных для редко используемого устаревшего приложения, и потому он будет довольствоваться более «тихоходными» и не столь дорогостоящими средствами хранения данных. Когда вы работаете со специалистами в области хранения данных, дабы удостовериться, что ваши требования удовлетворены, важно иметь четкое представление о типах нагрузок и о целевом уровне быстродействия системы ввода-вывода. Проиллюстрирую эту мысль. Представьте себе подключенный по сети SAN массив жестких дисков общей емкостью 300 Гбайт. Совокупное дисковое пространство можно делить на части и экспонировать разными способами, каждый из которых тем или иным образом влияет на производительность дисков. К примеру, десять упомянутых дисков можно сформировать в виде массива RAID уровня 6. Это означает, что два накопителя используются для контроля по четности, а имеющееся дисковое пространство составляет (n-2) × размер диска (в нашем случае — 8 × 300 Гбайт = 2,4 Тбайт). Это хранилище емкостью 2,4 Тбайт может быть представлено в виде единого тома с одним номером LUN или разделено на тома меньшего размера с несколькими номерами LUN. Сервер, использующий данный ресурс (один или несколько номеров LUN), не имеет представления о том, как последний был создан во внутреннем устройстве. Архитектура RAID 6 обеспечивает высокое быстродействие на операциях чтения и низкую производительность при записи: дело в том, что перед началом операции записи необходимо рассчитать биты четности. Описанная конфигурация не подходит для журналов транзакций SQL Server, чья производительность определяется быстротой записи. Перейдем теперь в другой конец спектра. Те же самые десять накопителей общей емкостью 300 Гбайт можно выстроить в виде массива RAID уровня 1 с возможностью «зеркального» дублирования. В этом случае для хранения данных будет выделено 1,5 Тбайт дискового пространства. Скорость операций записи при использовании данного LUN будет намного выше, чем в приведенном примере, но объем дискового пространства, выделяемого для хранения данных, будет меньше. Итак, мы имеем ту же сеть SAN и те же диски, но условия функционирования сервера, потреб­ляющего данные с этих дисков, в двух описанных случаях резко различаются.

SharePoint в сетях SAN

Когда дело касается использования дискового пространства, действия SharePoint напоминают поведение младшего брата по отношению к старшим. Сама по себе платформа SharePoint инициирует не так уж много операций ввода-вывода, но она подбивает своих собратьев брать на себя всю тяжелую работу (и ответственность). В статье Microsoft «Capacity management and sizing overview for SharePoint Server 2010» (technet.microsoft.com/en-us/library/ff758647.aspx) вопрос о числе операций ввода-вывода, необходимых для функционирования SharePoint 2010, даже не поднимается; эта проблема рассматривается лишь применительно к системе SQL Server. Авторы статьи исходят из того, что скромные потребности программы SharePoint с избытком покрывает любое количество жестких дисков, которое вам удастся наскрести для обслуживания этой программы. И в большинстве случаев такое допущение справедливо. Но если вы работаете с сетью устройств хранения данных, дополнительное дисковое пространство может пригодиться вам для некоторого повышения управляемости SharePoint и для тонкой подстройки ее производительности. Если говорить об управлении, при использовании сетей хранения данных облегчается процесс корректировки размеров и числа жестких дисков, обслуживающих SharePoint. Как указывается в подготовленной специалистами Microsoft статье «Hardware and software requirements (SharePoint Server 2010)» (technet.microsoft.com/en-us/library/cc262485.aspx), единственное требование к дисковой подсистеме со стороны SharePoint ограничивается объемом дискового пространства для системного накопителя в 80 Гбайт. Собственно программе SharePoint много памяти не нужно: она использует порядка 1 Гбайт плюс память для журналов, файлов индекса поиска, а также для специальных решений. Но на этом диске полагается также размещать файлы Windows и всех соответствующих исправлений на несколько лет вперед. Кроме того, на диске должно быть место для размещения журналов регистрации SharePoint, а также место для выполнения дампа памяти в случае возникновения проблемы. Кроме того, имейте в виду, что в ситуациях, когда диски заполнены данными более чем на 90%, файловая система NTFS начинает «чудить», так что позаботьтесь о наличии дополнительного дискового пространства на случай непроизводительных затрат. Итак, для функционирования программы SharePoint требуется по меньшей мере 80 Гбайт памяти, но иногда этого бывает недостаточно. Если в вашей системе накопители SharePoint размещаются в сети хранения данных, расширить системный накопитель емкостью 80 Гбайт до, скажем, 120 Гбайт можно будет без особых проблем. Администраторы SAN повернут пару регуляторов, переключат несколько рычагов — и система Windows придет к выводу, что располагает физическим диском на 120 Гбайт. Несколько манипуляций с диспетчером Disk Manager — и память вашего сервера увеличилась на 40 Гбайт. А теперь попробуйте провернуть такую же операцию с физическим жестким диском. Еще одна область, в которой грамотное использование сети хранения данных может способствовать повышению эффективности SharePoint, — это сфера производительности. В том, что касается быстродействия, система SharePoint в большинстве случаев не создает особых проблем, и ее требования, скажем так, не слишком высоки. Для того чтобы считывать данные с локального диска, этой системе многого и не нужно, а то, что ей нужно, она загружает и кэширует. И все же в некоторых случаях высокое быстродействие дисков может повысить эффективность работы пользователей. Я имею в виду кэширование и поиск больших двоичных объектов. Рассмотрим для начала вопрос о кэшировании больших двоичных объектов (BLOB caching).

BLOB-кэш

Когда речь идет о работе с SharePoint, к категории BLOB относят такие файлы, как JPG, GIF и MP3. Большие двоичные объекты, подобные названным, изменяются не слишком часто, и потому они — идеальные кандидаты для кэширования. А поскольку их размеры обычно превышают размер страницы, они более прочих объектов выигрывают от этого процесса. BLOB-кэширование — функция Microsoft IIS. Она настраивается в файле web.config каждого веб-приложения (обычно оно размещается по адресу C:\inetpub\wwwroot\wss\virtualdirectories). Поскольку перебирать файл XML строка за строкой с целью внесения тех или иных изменений мало кому под силу, разработчики SharePoint предлагают нам более простой метод — воспользоваться BLOB-кэшированием. Когда SharePoint создает веб-приложение, эта программа вводит все настройки, необходимые для BLOB-кэширования, в каждый файл web.config, но не активирует функцию BLOB caching. Замечательное решение! Теперь, чтобы воспользоваться преимуществами процесса BLOB-кэширования, нам достаточно найти в файле web.config соответствующую строку и изменить значение настройки активации с false на true. На рисунке показано, как данная строка выглядит до внесения изменений. Все эти сведения хорошо задокументированы специалистами Microsoft. В рамках данной статьи нас интересуют лишь параметры location и maxsize. По умолчанию параметр location привязывается к накопителю C. И это вполне логично, поскольку накопитель с таким обозначением имеется на каждом компьютере Windows. Однако эксперты рекомендуют освобождать накопитель С от всех файлов, кроме самых необходимых, и файлы кэшированных объектов не составляют исключения. Эти файлы следует размещать на вспомогательном накопителе. Вот здесь-то нам и может пригодиться сеть хранения данных. Ведь мы активируем средства кэширования прежде всего для того, чтобы повысить производительность работы конечных пользователей. Всякий раз, когда IIS может считать файл с локальной системы, вместо того чтобы докучать запросами внутренним компонентам экземпляра SQL Server, такой файл быстрее попадает в руки пользователей. Размещая BLOB-кэш на накопителе SAN, настроенном для достижения высокого быстродействия, мы обеспечиваем ускоренную доставку этого файла пользователям. Параметр maxsize определяет максимально возможный размер (в гигабайтах) большого двоичного объекта соответствующего веб-приложения. По умолчанию параметр имеет значение 10 Гбайт. Чем объемнее кэш, тем больше данных мы можем кэшировать и извлекать за короткое время. Не забывайте, что данная настройка задается для конкретного веб-приложения, так что вам нужно будет заранее позаботиться о выделении достаточного дискового пространства. Кроме того, вам придется редактировать файлы web.config для каждого веб-приложения на каждом сервере своей фермы.

 

Перед активацией функции BLOB-кэширования
Рисунок. Перед активацией функции BLOB-кэширования

Поиск

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

Начнем с индексирования. При его выполнении (а также при обходе контента, что является близкой по содержанию задачей) SharePoint тщательно исследует собственное содержимое, а также содержимое других указанных источников контента в поисках документов, которые предполагается сделать доступными для поиска средствами SharePoint. Эти файлы сканируются, а затем копируются в оперативную память сервера индексирования, где они с помощью фильтра iFilter разбиваются на составляющие (эта процедура чем-то напоминает разбивание кокоса ударом о камень), и все слова вводятся в список. Слова записываются в индексные файлы файловой системы сервера индексирования. Чем быстрее сервер индексирования может извлечь эти слова из памяти и поместить их в свою файловую систему, тем быстрее он может переходить к следующему файлу в списке. При этом нужно иметь в виду, что чем объемнее становится пул SharePoint, тем большую важность приобретает время сканирования. Высокопроизводительный SAN-накопитель, обслуживающий сервер индексирования, может способствовать сокращению этого показателя.

По завершении индексации файлы становятся доступными для поиска пользователями. Вот здесь-то на сцене появляются серверы запросов. Когда серверы индексирования индексируют файлы и записывают полученную информацию в свою файловую систему, эта информация объединяется с существующими индексными файлами серверов запросов. Когда пользователь ищет документ в SharePoint, в действие вступают серверы запросов. Они сравнивают предложенные пользователем условия поиска с индексными файлами своей файловой системы в поисках совпадений. С ростом фермы увеличивается и число документов, которые должен «перелопатить» сервер запросов. Времени на выполнение пользовательских запросов уходит все больше и больше. Наконец наступает момент, когда чаша терпения пользователей переполняется, и в ходе ожидания они начинают предаваться размышлениям о том, как бы половчее досадить главному виновнику своих страданий — администратору. Перенеся индексные файлы на накопитель SAN с высоким быстродействием, вы сократите время, необходимое для выполнения запросов. К вашим пользователям вернется хорошее настроение, а вам не придется опасаться происков измученных страдальцев.

Как и в случае с BLOB-кэшем, о котором речь шла выше, самым лучшим решением является перенос индексных файлов с диска C на другой накопитель. Если же ваш компонент запроса настроен таким образом, что индексные файлы сохраняются на накопителе C, не расстраивайтесь. Служба поиска предусматривает возможность изменений и позволит вам перенести индекс на другой накопитель по первому требованию. Чтобы это сделать, внесите изменения в топологию службы поиска Search Service Application Topology в центре администрирования SharePoint Central Administration. Для каждого из индексных разделов измените значение поля Location of Index. На экране приведен пример, где в качестве местоположения указан накопитель D, который, будем надеяться, является сверхскоростным накопителем сети хранения данных.

 

Перемещение индексных файлов
Экран. Перемещение индексных файлов

Я рекомендую изменять лишь буквенное обозначение накопителя, не вникая в подробности маршрута. Перенося файлы индекса на новый накопитель, оставляйте их на «привычных» местах. Таким образом вы упростите свою задачу, когда вам придется иметь дело с материалами, содержащими ссылки на файлы, размещенные в каталогах по умолчанию, а также задачу сотрудника, который займет вашу должность, когда вас назначат большим начальником или вы выиграете главный приз в лотерее. Внеся изменения в маршрут, нажмите ОК, а затем кнопку Apply Topology Changes.

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

Виртуализация в сети SAN

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

Все известные технологии виртуализации обеспечивают хостирование гостевых систем на накопителях SAN. Определяя параметры конфигурации SAN-накопителей, на которых будет размещаться та или иная ферма, принимайте во внимание назначение фермы (разработка продуктов, тестирование или производство). К примеру, в фермах для разработчиков все накопители могут размещаться на одних и тех же дисках, поскольку их производительность особого значения не имеет. Если серверы фермы относятся к категории «тихоходных», страдать от этого будут только разработчики, и меня это вполне устраивает. Пусть усваивают добродетель терпения. Тестовые фермы, пожалуй, должны отличаться чуть более высокой производительностью, так что соответствующие серверы следует размещать на более быстрых SAN-накопителях. Производственные фермы — если они виртуализованы и используют накопители SAN, — должны оснащаться самыми высокопроизводительными томами, которые можно получить на основе технологии SAN. К сожалению, вы как администратор SharePoint не располагаете удобным и эффективным методом определения того, как именно настроены ваши тома. Тут вам придется поверить на слово администраторам систем хранения данных. Чтобы ублажить их, не скупитесь на конфеты, а также статуэтки на темы компьютерной игры World of Warcraft.

SQL Server в сетях SAN

Быстродействие SharePoint на сто процентов зависит от производительности SQL Server — об этом я говорил бесчисленное количество раз. В начале настоящей статьи речь шла о том, как различные конфигурации SAN влияют на быстродействие. И нигде это влияние не проявляется так ярко, как в случае с SQL Server. Каждый документ, каждый элемент списка, каждый результат поиска и каждый профиль пользователя извлекается из базы данных SQL Server. Если эти базы данных хранятся на низкоскоростном накопителе, система SQL Server функционирует «на малых оборотах». А если SQL Server работает медленно, никакие фокусы с параметрами и никакие заклинания не смогут заставить SharePoint работать быстро. Вот как важна роль SQL Server.

В Интернете по адресу technet.microsoft.com/en-us/library/cc298801.aspx размещена подготовленная специалистами Microsoft статья «Storage and SQL Server capacity planning and configuration (SharePoint Server 2010)». В ней рассказывается о том, какие службы активно используют в своей работе операции ввода-вывода SQL Server и как рассчитать число операций ввода-вывода в секунду (I/O operations per second, IOPS), которое потребуется для организации работы SharePoint. В этом случае тоже нет возможности определить конфигурацию SAN-накопителей, используемых системой SQL Server. Однако вы можете определить IOPS накопителей системы с помощью таких инструментов, как Microsoft SQLIO disk subsystem benchmark tool. На основании полученной информации можно ответить на вопрос, в состоянии ли соответствующие накопители справиться с задачей обслуживания платформы SharePoint. Если выяснится, что такая задача им не под силу, вы можете добиться необходимого быстродействия совместно со специалистами по средствам хранения данных. Отметим попутно, хотя данная статья посвящена накопителям SAN, что программа SQLIO столь же эффективно работает и с физическими дисками, если у вас возникнет желание оценить их производительность. Загрузить это средство можно по адресу www.microsoft.com/download/en/details. aspx?&id=20163.

Магия SAN

Любому квалифицированному администратору SharePoint известно, что SharePoint — штука сложная. Данная технология имеет отношение к Windows, IIS, SQL Server — список можно продолжить. При этом во многих ипостасях SharePoint может расширять свои возможности, опираясь на замечательные свойства сетей SAN. Сети хранения данных могут применяться в среде SharePoint для кэширования часто используемых файлов или для хранения индексных файлов поиска. Серверы SharePoint можно виртуализовать на томах SAN, наконец, SharePoint могут использовать базы данных SQL Server, хранящиеся на томах SAN. Вне зависимости от того, каким образом вы применяете сети SAN в своей среде SharePoint, внимательно следите за рабочими характеристиками и обязательно поглядывайте время от времени на эти замечательные мигающие огоньки. Они просто зачаровывают.

Тодд Клиндт (todd@sharepoint911.com) — консультант фирмы SharePoint911 и обладатель сертификата SharePoint MVP

 

Поделитесь материалом с коллегами и друзьями

Купить номер с этой статьей в PDF