• Exchange 2010 и SIS

    Small Single Storage Unit В 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 больше нет.

    Максим Зинченко

    Оригинальное сообщение: http://msexchangeteam.com/archive/2010/02/22/454051.aspx

Комментарии

  1. да ну тебя, все самое интересное начинается! 🙂

  2. Интересная статья. Спасибо, Максим, за качественное изложение материала.

  3. Добрый день!
    Возник следующий вопрос. Каким образом мне, как администратору, возможно просчитать заранее для заданной архитектуры целесообразность миграции с Exchange 2007 на 2010?
    Потому что насколько я понял такой переход дает эффект только при использовании дисков больших объемов, таких как SAS и SATA.

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

  5. Пожалуйста, Виктория,
    приятно, что вам интересно.
    ITBand.ru и MaximumExchange.ru и дальше надеется радовать вас качественными и интересными материалами 🙂

  6. Не мудрено, что Microsoft не рекомендовала учитывать размер хранилища с SIS. Человеческие факторы выносим в отдельные риски 🙂

  7. Ну в каком-то смысле вы правы.

  8. Добрый день. Если развертывать Exchange 2010 на виртуальной машине (Hyper-V Server 2008 R2) можете оценить (или привести материалы ) на сколько снижается производительность системы при использовании динамического виртуального диска в сравнении с фиксированным виртуальным диском?

  9. По последним данным разница составит 1-4%, что вообще не является критичным. Именно поэтому МС дало добро на использование динамических дисков в продакшн.

  10. Кстати, видел ли кто-нибудь сравнительные характеристики производительности Exchange Server на Vmware и Hyper-V? В особенности дисковые подсистемы и процессоры на CA, MB.

  11. Cтатья образец для подражания! не часто можно увидеть статьи с таким доходчивым и вдумчивым изложением.Автору респект.

  12. Спасибо за ответ! Думаю, что по мере внедрения, будут еще вопросы.
    Насчет сравнения Exchange Server на Vmware и Hyper-V, тоже интересует, нигде не встречал.

  13. Интересная статья, спасибо, Максим. Сейчас для меня exchange 2010 актуален, так как планируем переходит на него.

  14. Добрый вечер! Не удержусь от комментария!

    Я думаю, что такие изменения в архитектуре вполне оправданы и ориентированы в первую очередь на современные требования к надежности, производительности и упрощение администрирования, на оптимизацию использования современных дисковых ресурсов.
    Отказ от использования SIS в Exchange 2010, а также переход на новую архитектуру и формат хранимых данных, являются достаточно серьезными изменениями.

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

  15. to: Владимир, alekzz, Sergey
    Спасибо 🙂 захвалили совсем, чего уж там, обычная статья.

  16. Отличная статья, с экскурсом в историю 🙂 Автору 5+. Хотелось бы тоже посмотреть сравнение характеристики работы Exchange на Vmware и Hyper-V.

  17. Я не думаю, что стоит ожидать какой либо особой разницы в работе Exchange cервера на Vmware(vSphere) и Hyper-V, отличной от обычной сравнительной характеристики работы этих двух систем виртуализации.
    Еще интересный момент, системы хранения данных дешевеют для малого и среднего предприятия, но по-моему такой тенденции уже не наблюдается для хранилищ в 15TB (raid-6) и выше на SAS дисках.

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

    –> Именно поэтому МС дало добро на использование динамических дисков в продакшн.
    http://technet.microsoft.com/en-us/library/aa996719.aspx:

    “The following virtual disk requirements apply:

    Virtual disks that dynamically expand aren’t supported by Exchange.

    Virtual disks that use differencing or delta mechanisms (such as Hyper-V’s differencing VHDs or snapshots) aren’t supported.”

    Где здесь “добро”?

  19. Отличная статья Макс. Впрочем как и всегда. Не устаю поражаться твоей эрудированности в данной области, хотя что еще можно ожидать от специалиста экстракласса:-). Ну а теперь по делу. На мой взгляд, прирост производительности несомненно есть. Опираясь на свой опыт могу сказать, что после переезда с версии 2007 на версию 2010 на абсолютно одинаковом железе дисковый массив реально вздохнул свободней в плане частоты обращений к данным, ну и размер базы мало-мало, но уменьшился. Что касаемо производительности на VHD дисках (несколько постов вверх). Коллеги, не упускайте тот момент, что все-таки это не полноценные железные массивы, а обычный сжатый файл, и пусть он и крутится на быстром харде, но задержки обращений несомненно будут. Хотя… для тестовой или промежуточной среды вполне подходящее решение.

  20. Статья отличная и очень детальная, перевод хорош =)

    “планы вашей архитектуры системы хранения данных должны учитывать такой расход” – как уже было замечено – в крупных энтерпрайзах это имеет только негативные последствия, потому что “стало дешевле” совсем не означает “бесплатно” и уж тем более дешевле стало менее качественно =) А там, где требуется надежность – стоимость таких СХД будет только расти.

    Из юмора: “Exchange 2012 – мы отказались от хранения сообщений в базе данных, теперь это простые несжатые файлы .eml и вы можете их разместить прямо у себя в Facebook и Twitter!”

  21. –> Не устаю поражаться твоей эрудированности в данной области, хотя что еще можно ожидать от специалиста экстракласса:-).

    Как я понимаю, Вы обращаетесь к Ross у Smith у, автору оригинальной статьи?

    (http://msexchangeteam.com/archive/2005/08/25/409819.aspx)

  22. Ну не удержался…
    >Отличная статья Макс.
    Статья действительно хорошая, но вот по поводу бурных аваций соглашусь с Evgueni, ИМХО, Макс всего лишь качественно перевел отличную статью блога разработчкив Exchange.
    > Впрочем как и всегда.
    Да уж, как всегда… Лично для меня очень странно, что блог Максима (maximumexchange.ru) наполнен на 80% переводами постов с msexchangeteam.com (по крайней мере последняя его часть).
    Да, далеко не все у нас свободно владеют английским и переводить интересные ресурсы необходимо, но ИМХО, не нужно себя при этом выставлять в роли автора!

  23. Кирилл, На счет Exchange 2012 и хранить в twitter – убил! 😀

  24. > Как я понимаю, Вы обращаетесь к Ross у Smith у, автору оригинальной статьи?
    Evgueni, завидовать не хорошо, в ваших комментариях нет ничего конструктивного. Это не тот блог, в котором кому-то интересно ваше личное отношение к автору.

    Павел Доброхотов, позвольте заметить, что на сайте maximumexchange.ru не 80% переводов, а не более 20%. Максим всегда дает ссылку на оригинальную статью в конце перевода, а также ссылку на совой перевод в комментариях на msexchangeteam.com. При этом он позиционирует себя как автора перевода, а не статьи.
    Скажите, вы часто видели “русских” авторов комментариев к оригинальным англоязычным статьям? А на maximumexchange.ru приходят, комментируют, спрашивают, получают ответы. Значит потребность в таких переводах есть, и их стоит делать. При этом хороший перевод занимает достаточно много времени и сил.

  25. Виктория, зря вы так переживаете, я ни в коем случае не хотел обидеть Максима, я сам читаю его блог и меня он очень радует, материал отличный и очень полезный, просто я немного не согласен с тем, как он преподносится, но это его личный блог и его право писать туда все, что он хочет.
    >Максим всегда дает ссылку на оригинальную статью в конце перевода
    Максим лишь добавляет в теги стати запись “MS Exchange team”, а это очень слабо намекает на происхождение материала.
    >При этом он позиционирует себя как автора перевода, а не статьи.
    Хорошо если так, только об этом ни где не сказано…
    >потребность в таких переводах есть, и их стоит делать.
    Полностью согласен и поддерживаю Максима в этом деле, более того, я часто рекомендую знакомым те или иные посты с его блога, т.к. считаю их грамотными и качественно сделанными.
    Предлагаю считать данный вопрос решенным и закрыть его, иначе модераторы нас накажут за то, что мы ушли от темы.
    Ещё раз прошу прощения за критику… “Ну не удержался…”

  26. –> Evgueni, завидовать не хорошо, в ваших комментариях нет ничего конструктивного.
    И не думал завидовать, в Ваших (и практически во всех) комментариях видно только “личное отношение к автору”, которое Вы мне приписываете…

    –> Скажите, вы часто видели «русских» авторов комментариев к оригинальным англоязычным статьям?
    Бывает, что касается англоязычных блогов technet, то сплошь и рядом…

    –> При этом хороший перевод занимает достаточно много времени и сил.
    Но при этом он остаётся максимум хорошим переводом.

    Обратите внимание на следующий русскоязычный ресурс: http://opsmgr.ru/default.aspx – ИМХО, образец для подражания и “личное отношение к автору” – уважение за профессионализм…

  27. Коллеги, будет вам спорить, в рубрику принимаются и статьи и переводы, и то и другое хорошо. Критика тоже полезна, она говорит о многом 🙂
    Посмотрите заголовок сайта – “Статьи об IT, Доступно о сложном”, это – главное.

  28. Интересная статейка. Было интересно почитать. 😉

  29. Уважаемый Максим, спасибо Вам большое за эту статью.
    Мне она оказалась на злобу дня. Я как раз сейчас учусь в Америке в коледже, пытаюсь вючиться по специальности Quality Assurance.
    И как раз совсем недавно нам рассказывали про Microsoft Exchange. Признаюсь честно, что не смотря на то, что я обладаю достаточно хорошим уровнем английского, прочитав то, что перевели Вы и как Вы это сделали для мена оказалось более понятным и даже простым. Вы делаете очень полезное дело, для людей работающих или собирающихся работать в этой отрасли. Спасибо большое. С удовольствием стану постоянной участницей этого сайта.
    С уважением,
    Александра

  30. И вам спасибо, Саша, за приятный коммент.
    Да, itband.ru хороший сайт с интересными материалами.

  31. Хвалить не буду, тут этого и без меня достаточно 🙂
    Хотелось бы узнать каким образом произвести расчет макс. требуемого дискового пространства для перехода с Exchange 2000 на 2010 при ограничении на размер почтового ящика в 200Мб?

  32. Размер почтового ящика, как имеющегося, так и планируемого можно рассчитывать исходя из следующих данных:
    Планируемый максимальный объем базы данных / количество почтовых ящиков, при учете размера квоты на ящик, текущего размера и роста ящиков за выбранный период. Досконально подробно об этом написано здесь.

  33. Ждем в чанге 2015 новую фичу с пупер обзорами и инновационными технологиями со страшным названием дедупликация! Майкрософт, такой Майкрософт.

  34. Очень жалко SIS. Отказ от него в энтерпрайсах оправдан. Однако, для небольших организации, с одним сервером с одной базой, SIS очень выручал. Особенно если широко используется много-адресный обмен вложениями. А сценарий такой очень часто встречается.

  35. Смутило предложение “реальный процент экономии дискового пространства, по сведениям – около 0-20%”. То есть переводя на русский, “реальный процент экономии дискового пространства, по сведениям – от никакого до весьма значтельного” :)))