Канал EMCProvenSolutions радует новыми видео:
понедельник, 8 августа 2011 г.
пятница, 5 августа 2011 г.
NUMA для vCPU в vSphere 5
Сегодня я бы хотел рассказать о мало освещаемой в блогосфере функции vSphere 5 – virtual NUMA. Что такое NUMA Антон уже описывал около года назад. Технология же virtual NUMA (vNUMA) позволяет гипервизору экспортировать в виртуальную машину данные о NUMA физического сервера. Преимущество этой технологии в том, что все современные ОС уже знают о NUMA и умеют с ней правильно работать, и, как следствие, смогут использовать данные о NUMA для получения максимальной производительности.
Для использования vNUMA необходимо, чтобы ВМ использовала vHW версии 8, а, во-вторых, vNUMA уже автоматически активирована для виртуальных машин с количеством vCPU от 8.
Еще один нюанс состоит в том, что если в ВМ ядер на сокет больше 1го, то размер vNUMA будет равен количеству ядер в сокете. Если же по какой-либо причине Вы выставили 1 ядро на сокет, то параметры vNUMA будут соответствовать NUMA ноде сервера.
Также существует набор тонких настроек vNUMA, изменять которые можно в разделе Aвvanced Settings для ВМ:
cpuid.coresPerSocket - Определяет количество ядер на сокете. Также отвечает за размер vNUMA, если таковая используется. Можно настраивать, если известна точная конфигурация NUMA на сервере.
numa.vcpu.maxPerVirtualNode - Если предыдущая чётко указывает количество ядер на узел, то это настройка указывает максимально возможное. Нельзя использовать их обе одновременно.
numa.autosize - каждый раз при включении ВМ размер vNUMA подгоняется под размер NUMA узлов сервера.
numa.autosize.once - то же самое, только работает один раз. Исключение: если из запущенной хотя бы 1 раз ВМ сделать шаблон – виртуальная машина, развёрнутая из этого шаблона будет иметь такую же vNUMA архитектуру, что и источник для шаблона.
numa.vcpu.min - минимальное количество vCPU, необходимых для создания vNUMA.
numa.vcpu.maxPerMachineNode - максимальное количество vCPU одной ВМ, которые могут работать в рамках одного физического NUMA узла.
numa.vcpu.maxPerClient - количество vCPU в NUMA клиенте. Клиент, в свою очередь - группа vCPU, которые обрабатываются как vNUMA, то есть как 1 объект. По умолчанию, 1 vNUMA является 1 клиентом, но если vNUMA больше pNUMA, то vNUMA может быть разбита не несколько меньших vNUMA клиентов.
numa.nodeAffinity - номера физических NUMA узлов, на которых исполяется виртуальная машина. Крайне не рекомендуется менять эту настройку, так как vmkernel не сможет нормально балансировать такую виртуальную машину между NUMA нодами.
Для использования vNUMA необходимо, чтобы ВМ использовала vHW версии 8, а, во-вторых, vNUMA уже автоматически активирована для виртуальных машин с количеством vCPU от 8.
Еще один нюанс состоит в том, что если в ВМ ядер на сокет больше 1го, то размер vNUMA будет равен количеству ядер в сокете. Если же по какой-либо причине Вы выставили 1 ядро на сокет, то параметры vNUMA будут соответствовать NUMA ноде сервера.
Также существует набор тонких настроек vNUMA, изменять которые можно в разделе Aвvanced Settings для ВМ:
cpuid.coresPerSocket - Определяет количество ядер на сокете. Также отвечает за размер vNUMA, если таковая используется. Можно настраивать, если известна точная конфигурация NUMA на сервере.
numa.vcpu.maxPerVirtualNode - Если предыдущая чётко указывает количество ядер на узел, то это настройка указывает максимально возможное. Нельзя использовать их обе одновременно.
numa.autosize - каждый раз при включении ВМ размер vNUMA подгоняется под размер NUMA узлов сервера.
numa.autosize.once - то же самое, только работает один раз. Исключение: если из запущенной хотя бы 1 раз ВМ сделать шаблон – виртуальная машина, развёрнутая из этого шаблона будет иметь такую же vNUMA архитектуру, что и источник для шаблона.
numa.vcpu.min - минимальное количество vCPU, необходимых для создания vNUMA.
numa.vcpu.maxPerMachineNode - максимальное количество vCPU одной ВМ, которые могут работать в рамках одного физического NUMA узла.
numa.vcpu.maxPerClient - количество vCPU в NUMA клиенте. Клиент, в свою очередь - группа vCPU, которые обрабатываются как vNUMA, то есть как 1 объект. По умолчанию, 1 vNUMA является 1 клиентом, но если vNUMA больше pNUMA, то vNUMA может быть разбита не несколько меньших vNUMA клиентов.
numa.nodeAffinity - номера физических NUMA узлов, на которых исполяется виртуальная машина. Крайне не рекомендуется менять эту настройку, так как vmkernel не сможет нормально балансировать такую виртуальную машину между NUMA нодами.
понедельник, 18 июля 2011 г.
VMware vSphere SRM Site Failover using EMC RecoverPoint Replication
Коллеги, рад сообщить, что на youtube появился канал EMC Proven Solutions с видеообзорами best practice.
Например, вот так выглядит интеграция VMware Site Recovery Manager и EMC RecoverPoint.
Например, вот так выглядит интеграция VMware Site Recovery Manager и EMC RecoverPoint.
воскресенье, 17 июля 2011 г.
vCat ищет себе vAdmin'а
Кот Канопус очень хочет найти себе хорошего Человека. Шотландский вислоухий, 1 год, очень общительный и ласковый. Отдается бесплатно, лишь бы человек хороший был.
Причина - мой график командировок.
пятница, 15 июля 2011 г.
vSphere 5. Storage vMotion.
Технология Storage vMotion позволяет мигрировать включенные ВМ между датасторами нон-стоп, без прерывания сервиса. Впервые она была представлена как механизм миграции ВМ с VMFS-2 на VMFS-3 без простоя ВМ при апгрейде с ESX 2.x на ESX 3.0.1. Мы даже не называли ее тогда Storage vMotion, а использовали что-то вроде Upgrade vMotion.
Быстро стало понятно, что для данной технологии существует множество применений - помощь при использовании различных уровней хранения данных, миграция ВМ при обслуживании СХД или вводе в эксплуатацию новой СХД / выводе из эксплуатации старой.
Механизмы работы Storage vMotion претерпели большое количество изменений с первоначального варианта. Сейчас, в vSphere 5.0, мы представляем новый улучшеный вариант, значительно повышающий производительность и надежность при миграции ВМ.
Быстро стало понятно, что для данной технологии существует множество применений - помощь при использовании различных уровней хранения данных, миграция ВМ при обслуживании СХД или вводе в эксплуатацию новой СХД / выводе из эксплуатации старой.
Механизмы работы Storage vMotion претерпели большое количество изменений с первоначального варианта. Сейчас, в vSphere 5.0, мы представляем новый улучшеный вариант, значительно повышающий производительность и надежность при миграции ВМ.
Размер блока и раздела VMFS
На днях к виртуальной машине (vCenter 4.1, ESX4.1) подключаю RDM-раздел и получаю ошибку "File[Name Datastore]nameVM.nameVM.vmdk is larger than the maximum size supported by datastore Name Datastore".
Ищу на http://kb.vmware.com/, получаю знание 1029697, где говорится правильно выбирайте VMFS block size. Вижу, где прокол (см. максимумы). Ограничение относится к VMFS.
Но самое интересное, что за год до этого на ESX 3.5 удалось подключить раздел размером 1TB, а виртуальная машина была на таком же VMFS-разделе, и после обновления на 4.1 прекрасно работает.. Возможно, дело в версии hardware виртуальной машины (как-нибудь проверю). Но вопрос не в этом. До этого случая я никогда не обращал внимание на вопрос выбора размера блока VMFS и создавал datastore по умолчанию (block size 1MB). Обозначилась необходимость понимать, на что влияют размер блока, размер раздела, и учитывать это при планировании хранилища.
Ищу на http://kb.vmware.com/, получаю знание 1029697, где говорится правильно выбирайте VMFS block size. Вижу, где прокол (см. максимумы). Ограничение относится к VMFS.
Но самое интересное, что за год до этого на ESX 3.5 удалось подключить раздел размером 1TB, а виртуальная машина была на таком же VMFS-разделе, и после обновления на 4.1 прекрасно работает.. Возможно, дело в версии hardware виртуальной машины (как-нибудь проверю). Но вопрос не в этом. До этого случая я никогда не обращал внимание на вопрос выбора размера блока VMFS и создавал datastore по умолчанию (block size 1MB). Обозначилась необходимость понимать, на что влияют размер блока, размер раздела, и учитывать это при планировании хранилища.
Подписаться на:
Сообщения (Atom)
Сообщения
