SharePoint в «облаке»

Майкл Ноэль (michael@cco.com) — партнер Convergent Computing, обладатель сертификата Microsoft SharePoint MVP и автор книг о SharePoint, ISA Server и Exchange Server

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

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

Что такое «облако»?

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

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

«Облачные» службы очень разнообразны: «облака» приложений, фермы инфраструктуры (как общие, так и специализированные) и частные «облака». Далее в статье каждый вариант «облака» будет описан подробнее.

«Облака» приложений

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

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

Компания Microsoft предоставляет еще один хорошо известный продукт — SharePoint Online, компонент Microsoft Office 365. Office 365 — «облачное» приложение Microsoft с функциями обработки сообщений (Exchange Online), мгновенного обмена сообщениями (Microsoft Lync) и совместной работы (SharePoint Online). Список из нескольких сторонних поставщиков «облачных» служб приведен во врезке «Поставщики «облачных» служб SharePoint».

На рисунке 1 приведено несколько версий Office 365 вместе с типичными ценами (они могут меняться). В рамках всех тарифных планов предоставляется доступ к SharePoint Online, хотя некоторые планы начального уровня (например, планы K1 и E1) обеспечивают только доступ для чтения к информации внутри SharePoint. Выбор плана Office 365 — сложное решение, которое зависит от размера компании, ее потребностей в обработке сообщений, особенностей рабочей силы и наличия или необходимости закупки полного набора инструментов Office (например, Office Professional Plus). Компаниям, заинтересованным в покупке Office 365, следует обратиться напрямую в Microsoft; цены различаются в зависимости от ситуации с лицензией и региона. Доступ к Office 365 и некоторым другим «облачным» продуктам SharePoint предоставляется не везде.

Рисунок 1. Версии Office 365

«Облако» инфраструктуры и частное «облако»

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

Частные «облака» часто создаются на платформах виртуализации, обеспечивающих быструю подготовку и отзыв, а также гибкую инфраструктуру систем. Например, поставщики частного «облака» могут предоставить клиенту возможность подготовить виртуальные серверы; поставщик просто взимает с клиента плату за время использования процессора, пространство для хранения данных и память. Такой вариант удобен для компаний с полностью виртуализованной средой SharePoint. Microsoft поддерживает такую топологию в рамках программы Server Virtualization Validation Program (SVVP). Однако при этом требуется уделить внимание требованиям SharePoint Server 2010 и Microsoft SQL Server к вводу-выводу дисковой подсистемы, памяти и процессора.

Главное преимущество «облака» инфраструктуры и частного «облака» — гибкость построения серверов по спецификациям клиента, настройка ферм в соответствии с конкретными предпочтениями и возможность задействовать всю функциональность SharePoint без необходимости самому физически управлять серверами. Например, клиенты могут извлечь преимущества из приложения-службы Microsoft Business Connectivity Services (BCS), чтобы сайты SharePoint напрямую обращались к данным, хранящимся в репозитариях бизнес-данных, физически размещенных на внутренних серверах баз данных. Такой подход применим, например, если компания желает показать внутренние данные об управлении связями с клиентами или сведения о продажах на сайтах SharePoint. Такого рода функциональность не всегда доступна в большинстве моделей «облака» приложений.

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

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

Однако с точки зрения миграции у «облака» инфраструктуры и частного «облака» есть важное преимущество: можно применять готовые и традиционные подходы к миграции. Например, коллекции сайтов можно переносить непосредственно через Windows PowerShell или с помощью инструмента Stsadm, не прибегая к сторонним инструментам.

Определяем требования к «облаку»

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

Определяем URL-адрес

Чрезвычайно важный вопрос — каким будет URL-адрес среды? В некоторых «облачных» решениях предусмотрена возможность использовать запоминающийся URL-адрес, такой как sharepoint.companyabc.com; в других этого сделать нельзя. Например, возможно, придется задействовать общий URL-адрес, такой как customerx.sharedproviderabc.com. Проблема может усугубляться текущим использованием внутренних URL-адресов для доступа к SharePoint, особенно если предстоит поэтапно переносить информацию в «облачное» решение. В результате определение будущего URL-адреса и способа переноса информации между URL-адресами становится трудной задачей.

Некоторые компании решают эту проблему, просто организуя в старой среде страницу, с которой клиенты перенаправляются прямо на соответствующий сайт. После переноса всех сайтов эту страницу можно изменить для автоматического перенаправления контента. Интеллектуальные системы уровня приложений, такие как Microsoft Forefront Unified Access Gateway (UAG) или Threat Management Gateway (TMG), также могут перехватывать и перенаправлять определенные пути внутри URL-адресов.

Устанавливаем требования к поиску

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

Перед миграцией необходимо знать истинные требования к поиску SharePoint. Например, если требуется расширенный поиск с использованием Microsoft FAST Search Server for SharePoint, то может понадобиться внутренний экземпляр Search, который обходит «облако» SharePoint, обеспечивая федеративный поиск как для внутреннего, так и для внешнего контента.

Деление информации на категории

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

Уникальная проблема, связанная с SharePoint в «облаке», заключается в вероятном отсутствии доступа к приложению Managed Metadata Service, которое позволяет единообразно применять теги метаданных в нескольких фермах. Если это приложение не предоставлено, то поиск решения для обозначения контента тегами, особенно в процессе миграции, становится еще более важным.

Требования к интерфейсу пользователя

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

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

Требования к безопасности

Безопасность целевой среды — критический элемент, особенно «облачной» структуры. По самой своей природе такие структуры обычно доступны для всех пользователей Интернета. Если меры защиты исходной среды надежны и хорошо продуманы, то разумно будет попытаться воссоздать их в целевой среде. Предполагается, что в «облачном» пространстве будут использоваться те же учетные записи или имена учетных записей. Но если меры безопасности изначально ущербны, то реструктуризация разрешений во время миграции окажется предпочтительной, хотя это может привести к другим проблемам с доступом во время миграции.

Определяем требования проверки подлинности

Важный вопрос при переходе на «облачную» службу — какие учетные записи будут применяться пользователями для регистрации? Выбор учетных записей и следует ли требовать от пользователей ввода имени пользователя и пароля для доступа к системе — важное решение с долгосрочными последствиями.

Имейте в виду, что не все поставщики «облачных» служб предоставляют способ проверки подлинности с собственными внутренними учетными данными клиента. Заметное исключение — Office 365, в котором для проверки подлинности можно использовать собственную среду Active Directory (AD) и службы Active Directory Federation Services (AD FS) 2.0. Для такого подхода, показанного на рисунке 2, требуется федерация между внутренней средой AD и поставщиками «облака»; в Office 365 это достигается с использованием AD FS. В результате пользователям не требуется дважды проходить проверку подлинности для доступа к среде SharePoint, почтовым ящикам или клиенту Lync.

Рисунок 2. Использование внутренних учетных записей AD для доступа к «облаку»

Альтернативный подход — использовать учетные записи, предоставляемые «облачной» службой, как показано на рисунке 3. Обычно в «облачных» службах есть этот вариант, в том числе в Office 365.

Рисунок 3. Использование учетных записей, предоставленных «облачной» службой

Очевидное преимущество варианта AD FS — единая процедура регистрации (SSO), но при этом возрастают масштабы инфраструктуры и сложность. Компании могут выбрать стратегию в соответствии со своими требованиями.

Перенос локальной среды SharePoint в «облако»

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

Составляем сценарий процесса миграции

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

Backup-SPSite -Identity  -Path  [-Force] [-NoSiteLock] [-UseSqlSnapshot] [-Verbose]

Затем с помощью команды Restore-SPSite можно поместить коллекцию сайтов в целевую ферму SharePoint. Существенное ограничение для этого подхода заключается в том, что уровень его детализации не выше, чем у самой коллекции сайтов, и требует административного доступа (на целевой ферме), редко предоставляемого «облачными» решениями SharePoint.

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

Export-SPWeb -Identity  -Path  [-ItemUrl ]
[-IncludeUserSecurity] [-IncludeVersions] [-NoFileCompression]
[-GradualDelete] [-Verbose]

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

Использование SharePoint Designer и Outlook 2010

Альтернатива миграции в малом масштабе с SharePoint — применение клиентского инструментария, такого как SharePoint Designer или Outlook 2010, который можно подключить как к исходной, так и целевой ферме SharePoint и использовать для ручного переноса содержимого из одной среды в другую. Этот сценарий масштабируется только для очень малой среды и не работает в случаях, если требуется переместить значительный объем информации. Преимущество такого подхода — возможность использования при отсутствии административного доступа к внутренним серверам. Другой вариант — задействовать представление Explorer и сопоставить накопители для перемещения содержимого, хотя такой подход нелегко масштабировать

Сторонние инструменты миграции

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

Учитываем достоинства и недостатки

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