Изолированные решения SharePoint 2010

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

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

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

Достоинства и недостатки

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

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

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

Однако существует несколько ограничений для изолированных решений. Функции безопасности ограничивают типы пользовательских настроек для продукта, которые могут быть развернуты как изолированные решения. Существует два основных способа контроля изолированных решений: политика безопасности доступа к коду (CAS) и подмножество вызовов интерфейса SharePoint API, которые не разрешено выполнять. Например, обычный рабочий процесс Visual Studio не может быть развернут как изолированное решение. Чтобы убедиться в его безопасности, весь код, который принадлежит изолированному решению, не может выполнять действий вне среды изоляции решения. Сюда входит и доступ к файловой системе, системному реестру и ресурсам сети. Таким образом, вызовов к внешним веб-службам или подключений к базам данных ERP нет.

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

Выполнение кода

Код, который содержится внутри изолированной среды решения, запускается не так, как первоначальный код или код в решении для фермы. Для кода, который не использует доверенного посредника, существуют два процесса, которые и применяются. На рисунке показано, как это работает на верхнем уровне. Предположим, пользователь затребует страницу, которая запускает пользовательскую веб-часть, развернутую внутри изолированного решения. Как и в случае запроса от браузера, сервер Web Front End (WFE), работающий на Microsoft IIS, получает запрос на страницу первым. Часть рабочего процесса IIS (W3WP.exe), которая называется Execution Manager, опознает, что это особый запрос, и делает собственный запрос к службе среды изоляции (SPUCHostService.exe), который может быть запущена на другом сервере (который я называю хостом изолированной среды). Затем служба среды изоляции создает новый рабочий процесс (SPUCWorkerProcess.exe), если это требуется для выполнения запроса. Данный рабочий процесс вначале проверит код, чтобы убедиться, что доступ к нему разрешен, а затем выполнит этот код, возвращая результаты в WFE.

Рисунок. Выполнение запроса к изолированному решению

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

Разрешение изолирования решений

Прежде чем запустить изолированные решения, нужно активировать их, запустив службу Microsoft SharePoint Foundation Sandboxed Code Service. Вы можете сделать это из Central Administration, System Settings, пункт Manage service on server. Запуск данной службы на сервере фермы делает сервер хостом изолированной среды.

При желании можно указать, как осуществлять балансировку запросов к среде изоляции. Настройки находятся в Central Administration, System Settings, Manage user solutions. Одна нужна для того, чтобы запускать код среды изоляции на том же самом сервере WFE, который получил запрос браузера. Этот код будет запускаться в раздельных процессах, как показано на рисунке, но WFE не будет отправлять запрос на другой сервер. Этот режим быстрее, но требует запуска кода службы среды изоляции на каждом сервере WFE. Другими словами, все ваши серверы WFE также являются серверами среды изоляции. Эта возможность предпочтительна в том случае, если у вас маленькая ферма или вы используете мало изолированных решений.

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

Развертывание изолированных решений

Развертывание изолированных решений — процесс несложный, и любой администратор коллекции сайтов может осуществлять его. Для этого нужно, прежде всего, выгрузить решение WSP в галерею Solutions, которая является частью каждой коллекции сайтов. Вы можете получить доступ к этой галерее, пройдя к Site Settings, Solutions от веб-сайта верхнего уровня в коллекции сайтов. Администраторы фермы могут это сделать, запустив команду PowerShell с именем Add-SPUserSolution из SharePoint 2010 Management Shell.

Выгрузив решение, следует активировать его. Это можно сделать с того же экрана. Активация решения распаковывает WSP и делает решение доступным для пользователей в коллекции сайтов. Чтобы сделать это из PowerShell, используйте команду Install-SPUser-Solution. Заметьте, что члены группы пользователей могут выгружать решения WSP, но только администраторы коллекции сайтов имеют право активировать их.

Помимо выгрузки изолированных решений, вы можете просматривать их онлайн-галерею Microsoft. Эта концепция напоминает реализованную Apple в магазине приложений App Store. На данный момент доступных решений пока нет, но вскоре все изменится. Ожидается, что галерея станет популярным способом поиска и загрузки расширений SharePoint.

Мониторинг изолированных решений

Чтобы предотвратить чрезмерное использование системных ресурсов изолированными решениями, вы можете контролировать и настраивать квоты ресурсов. Квота устанавливается для коллекции сайтов как единого целого, а не для индивидуального решения. В Central Administration перейдите к Application Management, Configure quotas and locks, и вы увидите эту настройку внизу экрана, как показано на экране 1.

Экран 1. Настройки квоты изолированного решения

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

По умолчанию квота ресурсов составляет 300 баллов для всех изолированных решений в коллекции сайта. Чтобы определить, много это или мало, нужно провести оценочные испытания решений, которые вы используете. Помимо экрана 1, вы можете задействовать такой сценарий PowerShell для настройки квоты ресурсов для коллекции сайта:

$site = Get-SPSite "http://siteurl"
$site.Quota.UserCodeWarningLevel = 200
$site.Quota.UserCodeMaximumLevel = 400

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

Для просмотра списка всех 14 счетчиков и того, как баллы высчитываются для каждого из них, запустите команду PowerShell:

[Microsoft.SharePoint.Administration
   . SPUserCodeService]:: Local
   . ResourceMeasures | Select Name,
   ResourcesPerPoint

Ради экономии места я не буду писать здесь все команды, а представлю только одну из них — CPUExecutionTime. По умолчанию значение равняется 200 ресурсов на балл. Для того чтобы сделать загрузку процессора «менее затратной», просто увеличьте это значение. Используйте сценарий:

$cpu2= [Microsoft.SharePoint
   . Administration
   . SPUserCodeService]:: Local
   . ResourceMeasures | where {$_.Name
   -eq "CPUExecutionTime"}
$cpu2.ResourcesPerPoint = 400
$cpu2.Update ()

С такой настройкой 400 единиц CPUExecutionTime равны одному баллу. Подобным же образом, чтобы сделать CPUExecutionTime более затратным, используйте меньшее значение. Мой совет: не изменяйте это число, не имея на то достаточных оснований. Заметьте, что эти правила вычисления делаются на уровне фермы, поэтому изменения, которые вы вносите, применяются ко всем решениям во всех коллекциях сайтов.

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

Экран 2. Использование ресурсов

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

Другие возможности

Помимо мониторинга, вы можете полностью блокировать определенные решения. Это имеет смысл, если вам случайно встретится решение, которое становится причиной многих проблем. Вы можете выгрузить пакет WSP, а SharePoint не позволит кому-либо еще выгрузить его для любой коллекции сайтов. Это делается из того же самого экрана, где вы устанавливали настройки балансировки загрузки (Central Administration, SystemSettings, Manage user solutions).

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

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

Рэнди Уильямс (RWilliams@synergyonline.com) — старший консультант в компании Synergy Corporate Technologies, имеет звание MVP по SharePoint Server