Итак, с основными параметрами жёстких дисков мы уже разобрались. Второй этап – выбор типа RAID массива. Рассмотрим основные типы RAID массивов, их плюсы и минусы, а также вопрос о производительности наиболее часто используемых типов RAID, и их накладных расходах на запись.
четверг, 18 августа 2011 г.
четверг, 11 августа 2011 г.
Производительность СХД. Часть первая.
Мощность процессоров в серверах за последние 10 лет выросла в десятки раз, количество оперативной памяти тоже, тогда как у жёстких дисков производительность растёт строго линейно и весьма медленно. И если с процессорами и памятью всё просто и понятно – чем больше, тем лучше, то с дисками всё намного сложнее. И чаще всего производительность дисков и СХД является узким местом виртуальной инфраструктуры из-за неправильного сайзинга.
Сегодня мы поговорим о базовых факторах, определяющих производительность жестких дисков.
Сегодня мы поговорим о базовых факторах, определяющих производительность жестких дисков.
понедельник, 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 год, очень общительный и ласковый. Отдается бесплатно, лишь бы человек хороший был.
Причина - мой график командировок.
Подписаться на:
Сообщения (Atom)
Сообщения
