none
Совмещение Exch2007 и роли Hyper-V на одном сервере RRS feed

  • Вопрос

  • Мигрируем с Exch2003 на 2007. Первый был установлен на контроллер домена (ДК),  2007 так ставить не хочется.  После миграции первый сервер будет "устранен физически".
    Ставить еще один физический сервер на роль контроллера домена не хочется. Возникли мысли поставить ДК на виртальную машину, которая будет хоститься на том же сервере на котором установлен Exch2007 (будут установлены хранилище мейлбоксов, клиентский доступ и роль концентратора). Для отказоустойчивости в этом же сайте есть еще один ДК (с ролью GC) поэтому проблем с очередностью загрузки быть не должно.
    Какие могут быть подводные камни такого софмещения ролей? Как сильно скажется такое совмещение на производительностьи обоих ролей?
    • Перемещено Hengzhe Li 12 марта 2012 г. 10:46 forum merge (От:Exchange Server 2007)

Ответы

  • Такой сценарий крайне не рекомендован. При виртуализации бизнес-приложений используется основная ОС только в качестве носителя роли гипервизора. А приложения виртуализируются уже внутри системы.
    http://okrylov.wordpress.com
    • Помечено в качестве ответа Kirill Vereschagin 8 мая 2009 г. 7:32
    Модератор
  • Поискал еще информации в интернете, офф. статей от МС не нашел, но кое что прояснил следующий коментарий:

    "What you outline makes sence for a lab or development environment, but I would not recommend it for a production environment.

    If you are building this setup to support folks in day to day operations (such as a single or branch office) you should not install other services into the Hyper-V Host.

    There are many reasons for this, but we can generally lump it all up to overhead.

    When the Hyper-V role is installed the OS that you installed on baremetal becomes a hybrid VM.  And it is given constraints.  Its now has the load of the VMBus, manages VMs, keeps everyone in line, networking, storage, etc.  (in a far different way thatn it does before Hyper-V is installed).

    For most folks this is an acceptable trade off of performance for a small lab or demo environment - but for production the user experience will generally be poor.
    "

    Взят отсюда http://social.technet.microsoft.com/Forums/en-US/winserverhyperv/thread/59828619-bfc6-4018-b419-9c9f90ac011c
    • Помечено в качестве ответа Kirill Vereschagin 8 мая 2009 г. 7:32
  • Но хочется ознакомится с деталями - почему, чем чревато, в чем невыгодно. Лучше всего было бы получить ссылки на соответствующие статьи от МС или кого еще авторитетного в этом вопросе.

    Виртуализация — это, по определению, способ изоляции ролей друг от друга. Вы же предлагаете нарушить этот принцип, и совместить две роли на родительском сервере. Это поддерживаемый сценарий (до тех пор, пока одной из этих ролей не является контроллер домена AD DS). Однако, он не является рекомендуемым.

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

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

    • Помечено в качестве ответа Kirill Vereschagin 8 мая 2009 г. 23:12
    Модератор

Все ответы

  • Такой сценарий крайне не рекомендован. При виртуализации бизнес-приложений используется основная ОС только в качестве носителя роли гипервизора. А приложения виртуализируются уже внутри системы.
    http://okrylov.wordpress.com
    • Помечено в качестве ответа Kirill Vereschagin 8 мая 2009 г. 7:32
    Модератор
  • Спасибо за ответ!
    Но хочется ознакомится с деталями - почему, чем чревато, в чем невыгодно. Лучше всего было бы получить ссылки на соответствующие статьи от МС или кого еще авторитетного в этом вопросе.
  • Поискал еще информации в интернете, офф. статей от МС не нашел, но кое что прояснил следующий коментарий:

    "What you outline makes sence for a lab or development environment, but I would not recommend it for a production environment.

    If you are building this setup to support folks in day to day operations (such as a single or branch office) you should not install other services into the Hyper-V Host.

    There are many reasons for this, but we can generally lump it all up to overhead.

    When the Hyper-V role is installed the OS that you installed on baremetal becomes a hybrid VM.  And it is given constraints.  Its now has the load of the VMBus, manages VMs, keeps everyone in line, networking, storage, etc.  (in a far different way thatn it does before Hyper-V is installed).

    For most folks this is an acceptable trade off of performance for a small lab or demo environment - but for production the user experience will generally be poor.
    "

    Взят отсюда http://social.technet.microsoft.com/Forums/en-US/winserverhyperv/thread/59828619-bfc6-4018-b419-9c9f90ac011c
    • Помечено в качестве ответа Kirill Vereschagin 8 мая 2009 г. 7:32
  • Но хочется ознакомится с деталями - почему, чем чревато, в чем невыгодно. Лучше всего было бы получить ссылки на соответствующие статьи от МС или кого еще авторитетного в этом вопросе.

    Виртуализация — это, по определению, способ изоляции ролей друг от друга. Вы же предлагаете нарушить этот принцип, и совместить две роли на родительском сервере. Это поддерживаемый сценарий (до тех пор, пока одной из этих ролей не является контроллер домена AD DS). Однако, он не является рекомендуемым.

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

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

    • Помечено в качестве ответа Kirill Vereschagin 8 мая 2009 г. 23:12
    Модератор