Exchange 2010 и SIS

April 7th, 2010

В Exchange Server 2010 больше нет системы Единого экземпляра хранения объектов – SIS, Single Instance Storage.

Для тех, кто не очень знаком с SIS:
SIS (Single Instance Storage) — технология хранилищ Microsoft Exchange Server (v4.0 – 2007), позволяющая содержать в почтовой базе письмо и вложения в единственном экземпляре, независимо от количества отправителей и получаетелей этого письма, чьи почтовые ящики также располагаются в этой базе данных.
Другими словами, если пользователь отправляет письмо с вложением 10MB десяти другим пользователям, чьи почтовые ящики находятся в пределах одной почтовой базы – письмо с вложением в этой базе данных будет занимать 10MB, а не 100 или больше, а каждому получателю письма будет предоставлена индивидуальная ссылка на письмо (внешне ничем не отличающаяся от любого другого электронного сообщения).

Чтобы лучше понять, почему SIS больше не применяется необходимо обратиться к истории Exchange.

Во время разработки Exchange 4.0, Microsoft преследовала две основные цели, из чего собственно и получилась система SIS:

  • Гарантировать максимально быструю и эффективную доставку
  • Сократить объем дискового пространства, требуемый для хранения сообщений, поскольку оно ограниченно.

Exchange 4.0 (а в последующем Exchange 5.0 и Exchange 5.5) изначально разрабатывался как спецприложение для собственного департамента Microsoft. В те времена учётные записи пользователей группировались на основе серверов Exchange, согласно организационной структуре (чаще всего целая компания обслуживалась единым сервером). И поскольку тогда применялась только одна почтовая база данных, Microsoft постаралась задействовать SIS (хранение единственного экземпляра тела письма и вложений), как для эффективности хранения, так и для доставки сообщений. Единственным случаем создания копий экземпляра письма было событие редактирования пользователем собственного экземпляра сообщения.

И далее, почти 19 лет, эта особенность архитектуры баз данных Exchange оставалась неизменной:

Затем был Exchange 2000. К этой версии Microsoft значительно развила Exchange Server, все сообщения между серверами были приведены к SMTP, появились группы хранения (storage groups) и увеличено максимальное количество баз данных. В результате система стала использоваться не только в одном департаменте, но и во всей организации. Однако появление 20 баз данных несколько нивелировало эффект SIS на дисковое пространство, а вероятность нахождения отправителей и получателей и в одной базе снизилась. В тоже время доставка сообщений улучшилась за счёт программной оптимизации транспортных механизмов, так что транспортная система тоже перестала выигрывать от SIS.

В Exchange 2003 консолидация ресурсов на сервере сошла на нет, благодаря таким механизмам, как кэшированный режим (Cached Exchange Mode). Переход к универсализации от заточенности под отдельный департамент продолжился. Многие заказчики отходили от размещения почтовых ящиков на основе организационной структуры к размещению их в разных базах данных, по своему усмотрению. И опять эффект от наличия механизмов SIS был уменьшен.

В Exchange 2007 Microsoft ещё увеличила количество возможных баз данных, что несомненно опять снизило эффективность SIS. Так же в очередной раз были оптимизированы транспортные механизмы доставки сообщений, которые уже полностью перестали использовать какие-либо преимущества SIS. Архитектура информационного хранилища была модифицирована, и хранение тела письма в единственном экземпляре окончательно потеряло свою актуальность (однако оно сохранилось для почтовых вложений). В результате таких эволюционных изменений система SIS перестала показывать сколь-нибудь реальный процент экономии дискового пространства, по сведениям – около 0-20%.

Одной из ключевых идей при разработке Exchange 2010 было размещение почтовых ящиков огромного размера по наименьшей стоимости хранения. Дисковое пространство перестало быть краеугольным камнем в разработке приложений, дисковые объёмы стали стоить копейки, а IT отделы смогли свободно пользоваться преимуществами больших и недорогих дисковых носителей. И чтобы эффективней использовать подобные огромные дисковые объёмы можно увеличивать размеры почтовых ящиков (а также избавиться от PST файлов, задействовать личные архивы (Personal archive) и систему управления почтовыми сообщениями – MRM, Message Records Management). А при планировании систем хранения полезно учитывать не только производительность систем ввода-вывода, но и объёмы хранилищ.

Во время проектирования Exchange 2010 Microsoft осознала, что табличная структура почтовой базы данных, оптимизированная под SIS – тормозит инновационное развитие архитектуры хранилища, нужное для достижения современных целей. Для улучшения ESE и хранилища Exchange, профиля I/O систем (от множества мелких случайных операций к меньшему количеству больших и последовательных), а также устранения недостатка в количественных показателях, Microsoft должна была модифицировать схему хранения. В частности Exchange Server был переориентирован с групп хранения (storage group) на самостоятельные базы данных:

Такая архитектура, в совокупности с прочими изменениями ESE и движка хранилища (такими как “ленивые” обновления просмотра (lazy view updates), упреждение расхода дискового пространства, увеличение файла подкачки, дефрагментация b+ дерева, и т.п.), в результате выдает в Exchange 2007 не только уменьшение операций ввода-вывода на 70%, но и существенные возможности увеличения количества хранимых объектов вы быстродоступных каталогах.

В результате введения новой архитектуры и модификации ESE и хранилища возникла необходимость устранить некоторые побочные эффекты. Вместе с улучшением эффективности I/O операций, увеличился и расход дискового пространства. Фактически, размер баз данных в Exchange 2007 увеличился примерно на 20% по сравнению с предыдущими версиями. Для снижения этого эффекта Microsoft применила механизм адресной компрессии объектов (методом “7-bit” или “XPRESS” , являющийся реализацией LZ77 алгоритма от Microsoft), который сжимает заголовки и тело письма в текстовом или HTML формате (почтовые вложения не сжимаются, поскольку зачастую уже являются сжатыми). Результаты проделанной работы мы можем видеть на примере почтовых баз данных Exchange 2007.

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

Как видите, почтовые базы данных Exchange 2007 на 100% состоят из содержимого в формате RTF (Rich Text Format), что было одной из основных целей Microsoft для сжатия баз данных в последующем, в Exchange 2010. Также было обнаружено, что полученная смесь данных (77% HTML, 15% RTF, 8% текст, при среднем размере письма в 50KB) при сжатии дает результаты сравнимые с размерами баз данных Exchange 2007. Другими словами Microsoft сумела технологически уравнять рост баз данных с исчезнувшим эффектом технологии SIS.

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

  • Почтовые организации, пересылающие сообщения только в RTF формате. Алгоритмы компрессии Exchange 2010 не сжимают RTF сообщения, поскольку те уже и так находятся в наиболее сжатом виде.
  • Пересылка больших вложений множеству получателей. Например, отправка большого вложения (30 MB+) 20-ти пользователям. Даже 5 из 20-ти получателей, находящиеся в одной и той же базе данных Exchange 2003 вызовут хранение 30MB вложения всего в единственном экземпляре, вместо 5 отдельных копий. В Exchange 2010 такое вложение будет храниться в 5 экземплярах (занимать 150 MB в базе данных) и не будет сжато. Но в планы вашей архитектуры системы хранения данных должны учитывать такой расход. Требования к времени хранения данных и их удалению по истечении установленного срока, в таких случаях, также играет важную роль.
  • Производственные архивы организации, предназначенные для хранения неизменных копий некоторых сообщений также имели преимущество при системе SIS, поскольку базы хранили объект в единственном экземпляре.

Если вы просмотрите рекомендации для Exchange Server за последние 10 лет, вы не найдете в них рекомендации учитывать SIS при проектировании объемов хранилищ. Microsoft могла отметить несомненный эффект SIS на размеры базы данных, но не более того. Все рекомендации всегда диктовали условие проектирования хранилищ Exchange без учета SIS. И даже для специалистов, привыкших делать абсолютно точные расчеты – SIS не является аргументом в таких расчетах пространства дисковых массивов. Подобные точные расчеты требуют должного опыта управления и быстроты реакций на изменения в почтовой инфраструктуре, а также хорошего понимания процессов распределения и увеличения размеров почтовых ящиков.

Подводя итог, можно сказать, что Exchange 2010 изменил общее представление почтовой инфраструктуры. Архитектурные изменения и изменения в формате хранимых сообщений, проведенные Microsoft в Exchange Server предоставили возможность содержания огромных почтовых ящиков при общей низкой стоимости хранилища. Дисковые объемы перестали быть барьером хранения, дисковое пространство значительно снизилось в стоимости, уменьшив общие затраты на обслуживание. Вы можете развертывать системы высокой отказоустойчивости Exchange 2010 и без механизмов SIS, при общем снижении затрат совокупной стоимости, по сравнению с предыдущими версиями Exchange Server.

Так что SIS больше нет.

  1. April 7th, 2010 at 11:09 | #1

    Спасибо Макс!,

    На сколько я помню NetApp вроде как чтото там говорила про SIS, они чтото там подерживают, но я не вдавался в подробности.

    Так просто накладно если пользователи в одной базе, к примеру 10 пользовтелей получили 10Mb PDF фаил, так 100Мб, а с SIS былобы 10….

    • April 7th, 2010 at 18:34 | #2

      Да за что, Арман.
      Microsoft права в том, что диски стали большими и дешевыми, и экономить по мелочам в ущерб live replication, например, невыгодно с технологической точки зрения. DPM шикарно бэкапит Exchange на лету.

  2. Pavel
    April 8th, 2010 at 09:18 | #3

    Спасибо за пост – отлично написано.

    Возник вопрос – а можно как-то посчитать в имеющейся организации Exchange 2007 эффект от SIS в настоящее время?

    То есть например, Ваша база – 50 Gb, без использования SIS она была бы 53 Gb. Соответственно эффект SIS – 3 Gb.
    Или оно того не стоит?

    • April 8th, 2010 at 18:29 | #4

      Пожалуйста, Павел, мне тоже нравится тема )
      На следующей неделе она будет опубликована в конкурсе ITBand.
      И да, разумеется можно. Открывайте консоль Performance, там есть объект производительности MSExchangeIS (Information Store), его счетчики позоволяют видеть и размеры баз и проценты SIS.

  3. Pavel
    April 8th, 2010 at 15:54 | #5

    Поискал в интернете по этому вопросу – нашел информацию, что эффект SIS может достигать 70% объема базы.

    Вот цитата (взято отсюда – http://www.maximumexchange.ru/2009/05/07/microsoft-exchange-12-myths-about-disaster-recovery/):
    “Exchange имеет преимущества над многими известными конкурентами, типа Lotus Notes, Scalix или Zimbra, например в плане дедубликации, в следствии своей архитектуры оптимизированной передачи и хранения данных. Представьте себе пользователя, пересылающего 10MB аттачмент в письме, десятку своих коллег. В базе Exchange будет храниться только 10MB этого вложения, а не 100, как у вышеуказанных конкурентов. Это называется Exchange SIS, «Single Instance Store». Дедубликация расчитана на подобные примеры. А ведь она значительно снижает размеры хранилищ Exchange (обычно порядка 70%).”

    • April 8th, 2010 at 18:32 | #6

      :) все верно.
      Microsoft поступилась этим козырем, в пользу других улучшений.
      В частности потоковая репликация (как в самом Exchange, так и в DPM например) входили в конфликт с изначальным эффектом SIS – хранение копий сообщений в единственном экземпляре.

  1. No trackbacks yet.
Comments are closed.