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

, включая следующие.

  • Установка Exchange Server на физических серверах внутри организации. Этот вариант предполагает принятие новых решений по Exchange Server 2010, скажем, продолжать ли использование хранилищ сети SAN и возвращаться ли к накопителям с прямым подключением, и определение необходимого количества копий данных.
  • Виртуализация. В результате повсеместного распространения на протяжении последних 5 лет средств виртуализации для решений различного масштаба выгоды от виртуализации Exchange Server стали более ощутимыми, но проблемы остаются.
  • «Облако». Концепция не новая, «облачное» развертывание Exchange применяется по крайней мере с момента выхода в свет версии Exchange Server 5.5.
  • Гибридные среды. Этот подход сочетает в себе варианты локального и «облачного» развертывания Exchange Server.

Традиционный выбор

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

Без дополнительного программного обеспечения. Для функционирования Exchange требуется операционная система (которая может быть виртуализованной или нет). Однако когда дело доходит до виртуализации, чтобы сделать возможным функционирование операционной системы на физических компонентах, нужно использовать гипервизор того или иного типа (скажем, Microsoft Hyper-V, VMware ESXi или Citrix XenServer). Использование этих программных средств влечет за собой необходимость дополнительной подготовки персонала, постоянной поддержки и обслуживания, а значит, к трудовым и финансовым затратам, связанным с эксплуатацией сети, добавляются новые.

Для функционирования решений на базе «облака» часто требуются дополнительные программные пакеты, включая программные решения, обеспечивающие процедуру однократной регистрации single sign-on (SSO), которая избавляет пользователей от необходимости отдельно регистрироваться на каждом «облачном» ресурсе; федеративные службы, позволяющие работать с «облачными» решениями без регистрации, а также панель управления Control Panel или другое программное обеспечение, осуществляющее системное администрирование. Некоторые из этих решений нужно устанавливать на индивидуальных рабочих станциях конечных пользователей, для других требуются выделенные серверы, а также сотрудники, обладающие специальными знаниями и навыками администраторов.

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

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

Высокое быстродействие дисков. Используя традиционные подходы, можно не беспокоиться о накладных расходах, связанных с виртуализацией дисковых накопителей. Современные гипервизоры обычно обеспечивают доступ к ресурсам дисков в трех форматах: виртуализованный диск (форматы VHD или VMDK), транзитный диск (с назначением накопителя DAS и с доступом к нему без использования уровня виртуализации), а также iSCSI/Fibre Channel (с доступом к дистанционно размещенным и структурированным в виде блока дисковым ресурсам, как если бы они были локальными). Однако следует отметить, что одна из важнейших конструктивных характеристик, связанных с высокой производительностью Exchange, состоит в надлежащим образом спроектированной дисковой подсистеме. Это положение справедливо для всех систем, вне зависимости от метода их развертывания.

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

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

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

Виртуализация

Для эффективной работы современных средств виртуализации необходимо, чтобы образ одной операционной системы не мог негативно воздействовать на образ другой (более того, вообще никак не мог на него воздействовать). Такое положение обеспечивается особенностями структуры ядра операционной системы, а также самого «железа». При этом неважно, какие программы могут выполняться на виртуальных машинах — это может быть Exchange Server, Microsoft SQL Server, службы файлов и печати и т. д. Каждая виртуальная машина защищена от кода, выполняемого на всех остальных машинах.

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

Быстродействие процессора, превосходящее требования системы. Для работы первоначальной версии Exchange Server требовался процессор, мощность которого составляет ничтожный процент мощности современного процессора (речь идет о процессоре 80486 с тактовой частотой 66 МГц). Это при том, что в тот период как набор возможностей Exchange, так и требования к процессору для обеспечения такого набора возможностей были намного скромнее, чем сегодня, и нам просто повезло, что благодаря закону Мура ныне мы имеем многоядерные процессоры, по своим характеристикам многократно превосходящие уровень производительности, необходимый для эксплуатации большинства серверов. Благодаря этому обстоятельству становится экономически эффективной, а также эффективной с точки зрения расходования ресурсов эксплуатация множества виртуализованных серверов на платформе одного физического сервера — даже с учетом связанных с этим накладных расходов, определяемых необходимостью управления упомянутыми виртуализованными серверами средствами гипервизора.

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

Дешевая память. К числу ресурсов, к которым высокопроизводительные операционные системы питают особую слабость, относится память. Чем больше памяти, тем лучше! Для работы первой версии Exchange Server требовалась оперативная память объемом в 32 Мбайт — в 1996 году это было исключительно много, но данный объем памяти позволял серверу обслуживать от 100 до 400 пользователей. Сегодня серверу Exchange требуется оперативная память объемом не менее 4 Гбайт, а для того чтобы многоролевой сервер мог обслуживать от 100 до 400 пользователей, его необходимо оснастить оперативной памятью объемом от 12 до 16 Гбайт.

Даже недорогие компьютеры выпускаются с оперативной памятью не менее 2 Гбайт, а для потребительских 64 разрядных компьютеров стандартом является оперативная память емкостью 3 Гбайт. В сфере бизнеса типичная конфигурация среднестатистической рабочей станции или ноутбука все чаще включает в себя оперативную память емкостью 4 или даже 8 Гбайт. Мощные переносные компьютеры зачастую оснащаются оперативной памятью объемом 16 Гбайт.

На серверах, предназначенных для поддержки средств виртуализации, как правило, устанавливают оперативную память объемом от 64 до 128 Гбайт. Даже при настройке для таких приложений, как Exchange Server, экземпляров операционной системы, требующих больших объемов оперативной памяти, объединение нескольких серверов в один может быть весьма экономичным решением, обеспечивающим более чем достаточный объем памяти для удовлетворения потребностей упомянутых приложений.

Дешевое дисковое пространство. Для пользователей Exchange Server цена дискового пространства — весьма неоднозначный показатель. В версиях Exchange Server 2010 и Exchange Server 2007 разработчики продукта реализовали значительные конструктивные изменения, дабы оптимизировать выполнение системы Exchange на недорогих дисках с низкой скоростью вращения. По сути дела, массив из «тихоходных» дисков по 3 Tбайт со скоростью вращения 5400 об./мин можно свободно использовать для организации хранилища основных или архивных почтовых ящиков системы Exchange 2010. Такие, не отличающиеся высокой скоростью диски обычно называют «просто кучей дисков» (Just a Bunch of Disks, JBOD). «Тихоходные» диски обеспечивают свободу действий проектировщикам средств хранения Exchange, которые намереваются использовать средства виртуализации. Нет ничего невозможного в том, чтобы, применяя диски с невысокой скоростью вращения, добиться производительности, позволяющей выдерживать нагрузку сотен, тысяч и даже миллионов почтовых ящиков Exchange 2010 — если аппаратные компоненты будут настроены должным образом.

Однако стратегия использования недорогих дисков имеет и ряд явных минусов. Как правило, дешевые диски чаще выходят из строя (у них меньшее среднее время безотказной работы — mean time between failures, MTBF). Конструкция подсистемы JBOD отличается от схем, привычных для среднестатистического администратора Exchange и, как правило, требует дополнительного мониторинга. Поскольку у дешевых дисков показатель MTBF ниже, администратор должен иметь под рукой большее количество запасных частей и быть готовым чаще производить ремонт этих подсистем, что может обернуться более высокими затратами.

Для формирования дисковой подсистемы Exchange можно использовать любой из следующих ресурсов:

  • виртуализованные дисковые ресурсы (файлы VMDK или VHD);
  • RAID-массивы накопителей с прямым подключением (с использованием низкопроизводительных дисков);
  • RAID-массивы накопителей iSCSI или Fibre Channel (с использованием низкопроизводительных дисков);
  • транзитные диски (с использованием низкопроизводительных дисков).

Разумеется, допускается применение любого из перечисленных ниже традиционных решений с использованием более высокопроизводительных дисков:

  • виртуализованные дисковые ресурсы с использованием высокопроизводительных дисков;
  • RAID-массивы накопителей с прямым подключением (с использованием высокопроизводительных дисков);
  • RAID-массивы накопителей iSCSI или Fibre Channel (с использованием высокопроизводительных дисков);
  • транзитные диски (с использованием высокопроизводительных дисков);
  • виртуализованные диски сетей SAN.

При использовании недорогих дисков администраторы сталкиваются с рядом проблем, о которых следует знать. Во первых, применение «тихоходных» дисков становится возможным за счет активного потребления ресурсов памяти. Иными словами, не следует работать с «медленным» диском, если для приложения выделен минимальный объем памяти: в этом случае производительность окажется не идеальной и, возможно, не будет дотягивать даже до приемлемого уровня. Во вторых, для хранения содержимого почтовых ящиков (речь идет как об основных, так и об архивных почтовых ящиках) Microsoft допускает использование решений, не относящихся к категории RAID-массивов, но лишь при том условии, что на нескольких серверах хранится по меньшей мере три копии данных почтовых ящиков (то есть при использовании группы доступности базы данных DAG с основной копией плюс, как минимум, две дополнительные копии). Если же вы не располагаете тремя копиями данных, для обеспечения целостности данных и из соображений безопасности следует продолжать пользоваться решениями на основе массивов RAID. Напомню, что в случае применения решений JBOD необходимо осуществлять мониторинг каждого диска, к тому же администратор должен иметь в виду, что такие диски дают сбои чаще, чем более дорогостоящие устройства. Наконец, вы можете продолжать пользоваться дисковыми накопителями SAN или высокопроизводительными накопителями с прямым подключением, что, вероятно, даст вам возможность обслуживать большее число почтовых ящиков в расчете на сервер, нежели при использовании JBOD. Однако диски JBOD могут обеспечить прекрасные характеристики для максимума рекомендуемых активных почтовых ящиков в расчете на один сервер Exchange (от 4000 до 5000 ящиков); следовательно, если главное для вас — высокое быстродействие, переходить на дорогостоящие диски необходимости нет; правда, нужно иметь в виду, что такие компании, как NetApp и EMC, поставляют решения с весьма интересными возможностями.

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

Сетевые ресурсы, используемые с недогрузкой. По производительности типичная современная сеть намного превосходит сети, эксплуатировавшиеся еще несколько лет назад. В США типичным является канал связи с настольной системой с пропускной способностью 100 Мбит/c, а коммутирующие узлы во многих серверных залах принимают и отправляют данные со скоростью 1 Гбит/c и даже 10 Гбит/c. Виртуализация сети представляет собой механизм для совместного использования полосы пропускания сети несколькими виртуальными машинами.

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

В случаях когда пропускная способность в 1 Гбит/c или в 10 Гбит/c не удовлетворяет потребности виртуального сервера, поскольку на нем размещается несколько виртуальных машин, которым приходится активно использовать сетевые каналы связи, гипервизоры обеспечивают назначение виртуализованным образам нескольких виртуальных сетевых плат (а также нескольких виртуальных сетевых коммутаторов). Сетевая полоса пропускания, доступная виртуальным машинам, ограничивается только числом имеющихся гнезд, в которых можно устанавливать физические сетевые интерфейсные платы.

Аппаратная независимость от виртуальных машин. Я уже касался некоторых проблем, связанных с виртуализацией аппаратных компонентов, но еще ничего не сказал о таком важном аспекте, как аппаратная независимость. Когда вы создаете виртуальную машину, сетевые интерфейсные платы, процессор, дисковые накопители IDE и т. д. виртуализуются в типичный набор аппаратных компонентов. Эти компоненты идентичны вне зависимости от того, выполняется гипервизор на самом современном оборудовании или на сервере, который вы собрали три года назад. Не составляет никакого труда переместить виртуальную машину с одного компьютера, на котором выполняется Microsoft Hyper-V, на другой, где выполняется Hyper-V, или с одного сервера, на котором выполняется VMware ESX, на другой сервер, выполняющий ESX. Перемещение образов с одного гипервизора на другой — задача более сложная, и этой темы мы не будем здесь касаться.

Если на вашем сервере произошел катастрофический сбой, приведение виртуальных машин в рабочее состояние не составит особого труда. Достаточно установить гипервизор на другом физическом сервере и затем восстановить серверные образы с резервной копии (или с другого члена кластера). Это гораздо проще, чем восстанавливать сервер с резервной копии состояния системы или с любой резервной копии исходного состояния системы. Простые процедуры восстановления с резервных копий весьма полезны при работе с ролями Exchange, которые сохраняют мало сведений о состоянии (скажем, узловой транспортный сервер) или вообще не сохраняют таких сведений, (например, сервер клиентского доступа). Однако простое восстановление с резервной копии вряд ли можно назвать удачным решением, когда речь идет о сервере почтовых ящиков, содержащем жизненно важные данные.

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

«Облако»

Должен признаться, что все эти разговоры об «облаках» меня несколько утомили. Название новое, но о концепции этого сказать нельзя — с тех пор, как были разработаны основные функции «облака», прошло уже более десяти лет. Конечно, сегодня мы имеем дело с более развитым «облаком», чем десять лет назад. Тогда мы могли устанавливать Exchange на оборудовании внешнего подрядчика. У нас была возможность размещать веб-сайты на серверах аутсорсеров. Мы могли делать множество вещей — но, что называется, в индивидуальном порядке. Однако на рынке был представлен совсем небольшой набор средств интеграции, а функциональное наполнение продуктов было недостаточным.

Основным продуктом, поставляемым корпорацией Microsoft для работы в «облаке», был комплекс Business Productivity Online Standard Suite (BPOS), который включает в себя хостируемый Exchange, хостируемый Microsoft Office SharePoint Server (речь идет не о сервере Microsoft Office Share-Point Server, MOSS, а о службах Windows SharePoint Services, WSS), хостируемое решение для проведения веб-конференций и организации совместной работы Live Meeting, а также хостируемый сервер Microsoft Office Communications Server (OCS). По сравнению с решениями, развертываемыми в организации, все эти продукты обладают ограниченным набором возможностей. Но с учетом того, что ежемесячная плата за пользование комплексом составляла 10 долл. в расчете на одного пользователя (розничная цена в США), хостируемые приложения могут быть весьма привлекательными решениями для предприятий малого бизнеса.

В настоящее время специалисты Microsoft подготовили решение Office 365, которое, возможно, уже поступит на рынок к моменту, когда эта статья увидит свет. Бизнес-платформа Office 365 будет включать в себя обновленные версии продуктов семейства BPOS, а также значительное число новых функций. В комплект Office 365 войдут дополнительно BlackBerry Enterprise Server (предоставляется бесплатно), Microsoft Office Web Apps, сервер Exchange Server 2010 (модернизирован с уровня Exchange Server 2007), а также телекоммуникационный продукт Microsoft Lync 2010 (модернизирован с уровня OCS 2007). В результате пользователи получат возможность мгновенного обмена сообщениями, эффект присутствия, пакет Lync Meeting вместо Live Meeting, средства для осуществления звонков с одного компьютера на другой, а также для совместного использования аудио, видео и общего доступа к рабочему столу. В комплект поставки включены также средства для установки полнофункциональной версии SharePoint 2010 (вместо наделенной лишь ограниченными возможностями службы WSS); это позволит организациям на базе SharePoint публиковать профессиональные корпоративные веб-сайты.

Средства управления и контроля, которыми наделены все входящие в комплект Office 365 решения, намного лучше, чем соответствующие компоненты набора BPOS. Сравнивая Exchange 2010 с другими версиями Exchange, следует отметить, что в панели управления Exchange Control Panel (ECP) этого продукта реализованы дополнительные возможности настройки как для пользователей, так и для администраторов. Панель управления Office 365 предоставляет еще более широкие возможности. Многие настройки для отдельных серверов или отдельных организаций, которые ранее были доступны лишь из программы PowerShell или с панели управления Exchange Management Console (EMC), теперь могут применяться с помощью панели управления Office 365. Обладая всеми этими новыми функциями и возможностями, комплекс Office 365 может реально претендовать на то, чтобы заменить ряд локальных служб «облачными» службами.

В большинстве сетей для реализации решений, включенных в набор BPOS или в локальную версию Office 365, нужно иметь не менее одного сервера на каждое приложение, инфраструктуру Active Directory (AD), соединение с Интернетом, обладающее широкой полосой пропускания, а также финансовые ресурсы с целью приобретения программного обеспечения для серверов Windows, серверов приложений и лицензий клиентского доступа. Чтобы окупить вложенные средства, может потребоваться значительное число пользователей или эксплуатация в течение длительного времени. Однако для организаций, которые уже располагают практически всеми необходимыми компонентами инфраструктуры, преобразование расходов по капитальным вложениям, capital expenditure (CapEx) в ежемесячные текущие издержки, operational expenditure (OpEx), возможно, не имеет смысла.

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

Еще одно потенциальное преимущество, обеспечиваемое «облачными» серверами почтовых ящиков, сводится к тому, что локальной организации больше не приходится заниматься ни резервным копированием, ни восстановлением данных — ответственность за эти участки работы возлагается на поставщика «облачных» услуг. Однако при таком раскладе процесс принятия решений существенно усложняется. Прежде всего, организация должна удостовериться, что средства резервного копирования и восстановления, которыми располагает компания — провайдер услуг, соответствуют потребностям этой организации с учетом применяемых юридических норм, а также особенностей корпоративной политики. Организации обязаны выполнять целый ряд требований, связанных с содержимым данных и режимом их хранения; эти требования определяются в зависимости от типа бизнеса, а также от страны, в которой действует организация. Упомянутые требования касаются политик хранения (но не ограничиваются ими), возможности выполнения операций поиска и обнаружения, очистки данных после непреднамеренной утечки конфиденциальных сведений в незащищенную среду, локализации информации о кредитных картах и других сведений, идентифицирующих личность Personally Identifiable Information (PII), а также физического места хранения данных. Организации должны тщательно проанализировать политики и возможности компании — поставщика услуги.

Особое внимание следует также уделить измерению и мониторингу доступности услуг подрядчика. Что бы ни утверждали провайдеры, простои случаются — такова жизнь. В соглашение с поставщиком услуг необходимо включать конкретные требования по доступности, а также определять в нем санкции, которые будут наложены на аутсорсера в случае несоблюдения этих требований. Соглашения подобного типа широко известны как соглашения об уровне обслуживания service level agreements (SLA). В них следует также прописывать механизмы передачи разрешения проблем на более высокий уровень иерархии, порядок извещения о возникающих неполадках, четкие определения, устанавливающие владельца данных, которые хранятся у поставщика услуг, а также порядок их восстановления в случае прекращения оказания услуг.

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

За выполнение всех требований к хостирующей компании приходится платить. Небольшие организации могут не принимать эти критерии во внимание, но средние и крупные организации не могут позволить себе такой вольности, ибо цена вопроса — гарантия доступности.

Комбинированные решения

Пользователи платформы Office 365 могут реализовать некоторые возможности в «облаке» (за пределами своей территории), а другие — на своей территории. В сущности, с помощью служб Active Directory Federation Services (ADFS) или диспетчера Forefront Identity Manager 2010 (FIM 2010) вы можете распространить действие своего локального каталога AD на «облако». К примеру, можно выбрать вариант, в соответствии с которым 80% ваших почтовых ящиков Exchange будут находиться в «облаке», а 20% — на локальном сервере Exchange. Вряд ли такой сценарий станет типичным решением для предприятий малого и среднего бизнеса. Но комбинированное («локально-облачное») решение может представлять интерес для более крупных организаций, особенно если они заинтересованы в специализированном решении на базе платформы Office 365.

Разумеется, сочетание локальных и облачных средств — не единственный тип комбинированного решения. Существует (и довольно часто реализуется) и такая возможность: часть серверов Exchange виртуализуется, а часть — нет. Например, вы хотите «выжать» из имеющихся дисковых подсистем максимум быстродействия и гарантировать отсутствие искажений в сообщениях голосовой почты. В этом случае вы можете разместить серверы почтовых ящиков и единой системы обмена сообщениями Unified Messaging (UM) на физическом оборудовании, а транспортный сервер-концентратор и сервер клиентского доступа — на виртуализованных серверах.

Идеальное комбинированное решение может включать все перечисленные варианты. Так, вы можете задействовать локальные физические серверы, локальные виртуализованные серверы и разместить в «облаке» несколько служб.

Лучшее решение

Какое решение больше всего подходит для вашей компании? Ответ на этот вопрос зависит от многих факторов. Чтобы найти оптимальное решение для своей среды, необходимо надлежащим образом рассмотреть все соображения и определить, насколько они применимы к вашей организации.

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

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

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

«Облака» не за горами

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

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

Майкл Смит (Michael@theessentialexchange.com) — независимый консультант, имеет звание MVP Microsoft Exchange Server. Ведет блог theessentialexchange.com