среда, 11 декабря 2013 г.

Особенности кастомизации портала SCSM 2012 (R2)

В рамках многих проектов по SCSM 2012 (R2) я сталкивался с необходимостью изменения дизайна портала самообслуживания, без осуществления программирования компонентов Silver Light и SharePoint.

В данной статье я расскажу про некоторые HINTs, которые помогут Вам улучшить визуализацию.

Так выглядит портал в состоянии "по-умолчанию", без  изменения цветовой гаммы и только с добавлением иконок.





А вот так после изменений


 
Для начала разберёмся с компонентами, которые входят в состав SharePoint и не используют SilverLight. Они представляют собой два фрейма слевой стороны и сверху, в которых размещаются другие элементы: список меню, различные поля, управление SPS(F), имя пользователя и т.д.

Данные разделы можно очень эффективно изменять, используя дебаггер IE, SharePoint Designer и CSS стили Sharepoint.

Для этого:
1. Запускаем дебаггер IE кнопкой F12
2. Нажимаем стрелку в левом углу
 


3. Наводим её на интересующий нас компонент портала и нажимаем LMB (в данном примере s4-Leftpannel-content), после этого в левой стороне окна дебагера мы увидим имя компонента и дерево его настроек
4. Нажимаем в правом окне дебаггера Отслеживать Стили и ищем интересующую нас настройку, в данном случае это Background-colur;
5. В данном примере у меня уже переопределён и применён к порталу мой собственный CSS CustomSMPortal.CSS, о чём свидетельствует перечёркнутнутая настройка цвета фона выше и надпись !important;
6. Чтобы ещё раз переопределить стиль, мы открываем SharePoint Designer и загружаем родительский сайт, в данном случае это https://spf01:444



7. Далее переходим в раздел All Files/Style Library/Themable и создаём собственный CSS, как это сделано у меня.
8. Открываем пустой созданный файл стиля (выбрав файл нажмите Edit file



9. Открываем исходный MasterPage или файл стиля портала самообслуживания - он нам понадобиться для поиска компонентов и их описаний (SMPortalCSS.CSS).
10. Теперь найдём в нём нужный компонент s4-Leftpannel-content
 
11. Копируем содержимое кода в наш файл CSS и правим его, как на рисунке ниже.

 

Это задаст белый цвет для панели меню.

Аналогичным образом мы можем переопределить другие элементы портала, реализованные на SPS(F). Вы можете добавлять, убирать (скрывать) различные элементы по собственному желанию.




ВНИМАНИЕ! Для того, чтобы Ваш стиль CSS применился, в MasterPage файле портала самообслуживания необходимо вставить следующую строку, где имя CSS файла - это имя созданного Вами шаблона.
.

 
ПРИМЕЧАНИЕ! После того, как вы добавили новую строку в CSS и сохранили файл, перед тем, как посмотреть изменения на портале выполните отчистку кэша браузера средствами debugger'a. В противном случае будет применяться закешированная настройка.

Однако, при изменении дизайна фреймов, внесения дополнительных фреймов, кнопок и т.д. требуется уже детальная разработка кода для портала. Если у Вас нет подобного опыта, то не рекомендую упражняться в такого рода кастомизациях на рабочей системе.

Плюс данного подхода с созданием собственного файла стилей в том, что те изменения, которые вы сделали на стенде, вы можете без труда перенести в производственную среду портируя стиль CSS на портал самообслуживания SCSM 2012 (R2).

Теперь разберёмся с компонентом SilverLight в центральной части портала. К сожалению, "из коробки", данный компонент достаточно плохо поддается кастомизации.

В первую очередь нас интересует файл Settings.XML, который можно найти в C:\inetpub\wwwroot\System Center Service Manager Portal\ContentHost\Clientbin

В данном файле вы можете изменить следующие настройки компонента SilverLight портала самообслуживания:
  • Цвета компонентов и шрифтов;
  • Размеры шрифтов;
  • Вес шрифтов;
  • Стиль шрифтов;
  • Количество строк на странице;
  • Количество статей баз знаний на странице;
  • Количество запросов на обслуживание на странице;
и некоторые другие параметры.

Так же, в статье "На портале самообслуживания SCSM 2012 не отображаются предложения сервисов" я писал о проблемме при отображении услуг портала на разных языках.

Решение проблемы предложенное коллегами "из-за бугра" не совсем комфортно.

Есть другое решение. Для исправление этой проблемы необходимо прибегнуть к редактированию файла настроек SilverlightModule_StringResources.ru.resx, находящемуся в C:\inetpub\wwwroot\System Center Service Manager Portal\ContentHost\Clientbin\ru (в моём случае на англоязычном портале SCSM 2012, услуги с локализацией ru-RU не отображались).

Данный файл содержит локализацию надписей портала на русский язык (их можно отредактировать), включая локализацию сервисов.

Исходный код выглядит следующим образом:

<resheader name="writer">
    <value>System.Resources.ResXResourceWriter, System.Windows.Forms, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089</value>
  </resheader>


Проблема заключалась в параметре строки, который я выделил жёлтым цветом.

После приведения кода к следующему виду:

<resheader name="writer">
    <value>System.Resources.ResXResourceWriter, System.Windows.Forms, Version=4.0.0.0, Culture=ru-Ru, PublicKeyToken=b77a5c561934e089</value>
  </resheader>


Отображение услуг на портале для языков английского и русского стало работать корректно.

среда, 9 октября 2013 г.

Проектирование ЦОД, виртуализация: Жесткие диски, СХД и IOPs !!!

Disclaimer: данная статья не является каким либо Best Practice от какого либо вендора и является осмыслением собственного опыта, а так же понимания процессов. Вся информация предоставляется "as is" без каких либо гарантий. Данная статья является продолжением общего цикла о виртуализации на Windows Server 2012, ссылки на другие статьи см. в конце;

Не многие задумываются о значении СХД при построении решений виртуализации, а так же значении системы доступа сервера виртуализации к СХД (iSCSI, FC, FCoE, SAS). Однако, даже имея супер мощные серверные платформы СХД может стать тем узким местом, которое сделает Вашу виртуализированную инфраструктуру нежизнеспособной, несущей больше рисков, чем выгоды.

Для начала кратко резюмируем то, что мы знаем о СХД, протоколах и методах соединения хранилищ и серверов и т.д. Итак...

Диски

Диски обладают следующими характеристиками:
  • интерфейс подключения (SAS, SATA и т.д.)
  • скорость вращения шпинделя Rotaitions Per Minute (RPM)
  • количество операций ввода - вывода в секунду
  • время "случайного" доступа к данным
  • кэш (ОЗУ)
Интерфейс подключения -  отвечает за скорость передачи данных от шины к диску и обратно. Каждый интерфейс имеет свои скоростные характеристики:

ПРИМЕЧАНИЕ! Информация в таблицах могла устареть или измениться с момента написания статьи.



Interface
AlternativeSpecificationClockMaximum
NamesDocumentThroughput (MB/s)Throughput (Mbit/s)
SSASerial Storage Architecture200 MHz40 MB/s320 Mbit/s
SSA 40400 MHz80 MB/s640 Mbit/s
Fibre Channel 1Gbit1GFC1 GHz100 MB/s800 Mbit/s
Fibre Channel 2Gbit2GFC2 GHz200 MB/s1600 Mbit/s
Fibre Channel 4Gbit4GFC4 GHz400 MB/s3200 Mbit/s
Fibre Channel 8Gbit8GFC8 GHz800 MB/s6400 Mbit/s
Fibre Channel 16Gbit16GFC16 GHz1600 MB/s12.8 Gbit/s
SAS 1.1Serial attached SCSIINCITS 417-20063 GHz300 MB/s2400 Mbit/s
SAS 2.0INCITS 457-20106 GHz600 MB/s4800 Mbit/s
SAS 3.0T10 Project: 2212-D for approval12 GHz1200 MB/s9600 Mbit/s
IEEE 1394Serial Bus Protocol (SBP)IEEE Std. 1394-2008400 MB/s3200 Mbit/s
SCSI ExpressSCSI over PCIe (SOP)T10 pre-standard8 GT/s985 MB/s7877 Mbit/s
USB Attached SCSIUASINCITS 471-20105 Gbit/s~400 MB/s~3200 Mbit/s
ATAPIATA Packet InterfaceNCITS 317-199833 MHz DDR133 MB/s
SCSI-1Narrow SCSISCSI-1 (1986)[15]5 MHz5 MB/s40 Mbit/s
Fast SCSISCSI-2 (1994)10 MHz10 MB/s80 Mbit/s
Fast-Wide SCSISCSI-2;10 MHz20 MB/s160 Mbit/s
SPI-5 (INCITS 367-2003)
Ultra SCSIFast-20SPI-5 (INCITS 367-2003)20 MHz20 MB/s160 Mbit/s
Ultra Wide SCSISPI-5 (INCITS 367-2003)20 MHz40 MB/s320 Mbit/s
Ultra2 SCSIFast-40SPI-5 (INCITS 367-2003)40 MHz40 MB/s320 Mbit/s
Ultra2 Wide SCSISPI-5 (INCITS 367-2003)40 MHz80 MB/s640 Mbit/s
Ultra3 SCSIUltra-160; Fast-80 wideSPI-5 (INCITS 367-2003)40 MHz DDR160 MB/s1280 Mbit/s
Ultra-320 SCSIUltra-4; Fast-160SPI-5 (INCITS 367-2003)80 MHz DDR320 MB/s2560 Mbit/s
Ultra-640 SCSIUltra-5; Fast-320SPI-5 (INCITS 367-2003)160 MHz DDR640 MB/s5120 Mbit/s
 http://en.wikipedia.org/wiki/SCSI


 


Название
Пропускная способность шины (Mbit/s)
Скорость передачи (MB/s)
eSATA
3 000
300
eSATAp
SATA revision 3.0
6 000
600
SATA revision 2.0
3 000
300
SATA revision 1.0
1 500
150
PATA 133
1 064
133.5
SAS 600
6 000
600
SAS 300
3 000
300
SAS 150
1 500
150

 http://ru.wikipedia.org/wiki/SATA

ПОДСКАЗКА! В данной статье содержиться сравнительное тестирование дисков с разными интерфейсами и производительностью (от 24.08.12) http://www.sgidepot.co.uk/diskdata.html

Скорость вращения шпинделя диска - отвечает за скороть доступа к данным с диска. Операции чтения или записи, осуществляемые на дисках, определяются, как ввод или вывод (I/O operations per second) или IOPs.

Существует несколько  показателей, которые были бы нам интересны:
  • Read IOPs Суммарное количество операций чтения которые осуществляются за секунду
  • Write IOPs Суммарное количество операций записи которые осуществляются за секунду
  • Total IOPs Суммарное количество операций записи/чтения которые осуществляются за секунду
  • Averange Random Access Time - время случаяного доступа к данным на диске
  • Queue Lenght- очередь диска.
Каждый тип диска имеет определенное количество IOPs-ов, средние данные по дискам примерно следующие:


RPMIOPS
15000 RPM~155-170
10000 RPM~110-125
7200 RPM~65-85

ПРИМЕЧАНИЕ! Данные приблизительные и могут отличаться от вашей конкретной ситуации. Для уточнения проведите тестирование дисков своей СХД или серверов.

Среднее время "случайного" доступа к данным или Averange Random Access Time - отвечает за скорость, с которой механизм жесткого диска может позиционировать головку чтения или записи  над нужной дорожкой. Время доступа - величина переменная, она полностью зависит от начального и конечного положения головок, поэтому в качестве характерного показателя выбирают среднее время доступа. В некоторых дисках данные размещаются не по всей пластине, а только по ее крайней части, что позволяет увеличить скорость чтения и тем самым существенно уменьшить время доступа.

Очередь диска - даёт нам понять количество запросов, ожидающих обслуживания. Количество ожидающих запросов ввода-вывода должно соответствовать продолжительности не более чем 1,5—2 оборота шпинделя, производимых физическим диском. К примеру, для 8 дискового массива длинна очереди не должна быть выше 14-16 при пиковой загрузке.

Интерфейсы подключения СХД к серверам и кэш RAID контроллера дисков

Это те элементы, которые возникают при взаимодействии хоста (сервера) с дисковой подсистемой и её контроллером. Чем выше скорость передачи данных, тем быстрее процессор получит возможность их обработать и не будет простаивать в состоянии idle.

Однако тут не всё так просто. Скорость передачи данных дисковой подсистемы можно условно разделить на две части:

первая относится к самим дискам и их взаимодействию с контроллером: доступ к поверхности диска (размещение головок диска и т.д.), для осуществления операций чтения или записи. Параметрические характеристики описаны в предыдущих разделах статьи. Скорость чтения-записи будет ниже для внутренних треков диска и больше для внешних. Так же на скорость доступа к данным влияет фрагментация диска и плотность записи данных. (Backend)

вторая: взаимодействие дискового контроллера и его кэш с хостом (процессором, ОЗУ и т.д.) (Frontend - between Application and Logical Volume)

Тут особую роль играет несущая или метод коммутации и протокол, а так же кэш.

Сначала о подключениях СХД в серверу: SAS интерфейс (может быть и Shared SAS), FC, DAS, Ethernet Network Adapter (iSCSI) или Ethernet  HBA  и т.д. Если говорить о количестве необходимых интерфесов подключения необходимо понимать два фактора:

  • Обязательно надо понимать, что стабильную работу виртуализированных сервисов компании даст не только отказоустойчивость на основе самих приложений, но и  на аппаратном уровне, поэтому чаще всего встречается рекомендации о минимум двух адаптерах подключения  от СХД к каждому узлу кластера; Так же наличие дублирующих элементов (соединения в кросс, запасных коммутаторов (если используются) и т.д.)
  • Достаточная пропускная способность интерфейсов. Здесь имеет смысл подумать о количестве информации, которая будет передаваться по этим интерфесам в разных режимах: загрузка ВМ, операционная нагрузка, при обращениях к сервисам ВМ (к примеру: базам данных), служебный трафик сетевых пакетов и узлов координаторов кластеров; Будет ли вам достаточно 1 Gbps сетевого адаптера или вам надо приобретать HBA 10 Gbps, или FC, а сколько их нужно? Последний пункт тоже влияет на стоимость решения...
Как определить достаточно ли пропускной способности? Частично тут нам может помочь MAP - Microsoft Assesment and Planning Toolkit (о данной утилите я писал встатье http://www.techdiving.pro/2012/10/blog-post_16.html). При оценке готовности к виртуализации этот solutions accelerator собирает данные о работе дисковых подсистем физического сервера: объёме данных и затрачиваемых IOPs (Maximum, Avarange) и другую полезную информацию.

Мы можем пересчитать затрачиваемые IOPs в мегабайт в секунду, к примеру, и тем самым получить примерный объём передаваемого трафика по сети к хранилищу (полоса пропускания). Да, к этому трафику так же добавится служебная информация, используемая протоколом транспортировки данных и это тоже можно учесть (объём служебной информации будет различаться, в зависимости от протоколов передачи данных).

MB/s = (IOPs * KB per IO) / 1024 , где KB per IO = размеру кластера на диске.

К примеру, у нас есть 25 серверов, потребляющих 85 IOPs в среднем, т.е.

((25*85)*4)/1024  = ~8,5 Mb/s (или ~66,4 Mbps), вроде бы одна карта 1 Gbps справится и плюс одна для резервирования, но существует не просто  режим стабильной работы, а так же загрузка систем и пиковые часы. Это тоже необходимо учитывать, чтобы понять возможные максимумы, которые необходимо заложить в рассчёт (опять же в этом нам поможет MAP или различные стресс-тест эмуляторы или методики рассчётов, которые существуют для продуктов Microsoft).

ПРИМЕЧАНИЕ! Не забывайте о том, что дополнительную нагрузку на СХД дают не только виртуальные машины, но и процессы, запускаемые на них (к примеру: проверка антивирусом виртуального рабочего места может очень серьёзно нагрузить СХД)

Так же мы можем пойти от обратного, к примеру, зная только размер кластера диска и объём данных, к примеру в мегабайтах в секунду,  которые мы будет прогонять по сети, мы можем определить и полосу пропускания (в секунду, в минуту, в час), но  и IOPs, которые необходимо получить от СХД..

IOPS = MB/s Throughput  * 1024  / KB per IO , где Mb/s Throughput можно получить, разделив утилизацию полосы пропускания в Mbps на 8.

Конечно в данных рассчётах существует погрешность, но в целом, исходя из показателей моего тестового стенда - это вполне похоже на правду (см. раздел статьи "К делу").

Отсюда, как следствие, можно получить приблизительное число, необходимых сетевых адаптеров, их типах, скоростях, а так же режимах работы MPIO, наиболее оптимальных для этих сценариев.











ПРИМЕЧАНИЕ! В Hyper-V 3.0, на сегодняшний день, нет возможности зарезервировать определённое количество IOPs за конкретной виртуальной машиной, только для хоста виртуализации или группы хостов. Такая возможность появиться в Windows Server 2012 R2, судя по CTP редакции, и будет называться Storage QoS.


А теперь о кэш:

Скорость взаимодействия процессора и оперативной памяти намного выше, чем время доступа к информации на диске. Именно для выравнивания этой разницы был придуман кэш диска (дисковой подсистемы или контроллера RAID).

Кэш устройств хранения или контроллеров увеличивает производительность системы за счёт оптимизации использования операций ввода-вывода.

Итак, на скорость доступа к данным влияют не только сами диски, но и кэш даннных котроллера и дисков, а так же технология передачи данных от контроллера к узлу виртуализации. Это необходимо учитывать при выборе дискового массива, контроллера и определении протокола взаимодействия между СХД и хостами. О некоторых нюансах использования iSCSI и FCoE.

ПРИМЕЧАНИЕ! Иногда необходимо отключить кэширование, такие ситуации возникают, когда целостность данных превалирует над скоростью считывания-записи.

Так же стоит обратить внимание на функционал Native Command Queue у дисков (см. ссылки).


RAID массивы

К сожалению, у каждого RAID массива есть определённое количество операций связанных с записью каких либо данных на массив. Данный "Administrative penalty", пожалуй назовём это так, способен существенно сказаться на производительности массива.


RAIDI/O Penalty
RAID 01
RAID 12
RAID 54
RAID 66
RAID 102
RAID DP2



К делу...

Итак, для теста я использовал полку NetApp FAS 2040 с 12 SATA 7,2 RPM дисками на RAID DP. Полка соединена с серверами виртуализации:
  • 2 сервера по 2 сетевых адаптера 1 Gb/s;
  • 1 сервер по FC;
  • 4 Ethernet адаптера по 1 Gbps на СХД
При создании платформы виртуализации не стоит экономить на СХД и дисках, к примеру, следующий график показывает, что происходит с полкой, при единовременном старте 8 виртуальных машин (замечу, что 2 из трех хостов виртуализации соединены с полкой по iSCSI 1 Gb/s).


Исходя из данных, которые я привёл, вы можете легко понять максимальную производительность системы хранения данных (о том, как посчитать производительность дисковой подсистемы в разных режимах см. ниже), и представить, что будет при единовременном старте или высокой утилизации 75 виртуальных машин , которые развёрнуты в нашем демо облаке на сегодняшний день.

Недостаточная производительность дисковой подсистемы может вызвать сбои в загрузки сервисов и самих операционных систем, либо сильно увеличит время прихода виртуальной машины в рабочее состояние, когда она способна обрабатывать запросы пользователей. Именно поэтому необходимо планировать порядок загрузки виртуальных машин и время "паузы", через которое те или иные машины будут стартовать в зависимости от приоритета. Более того, время отклика GUI интерфейсов виртуальных машин так же зависит от скорост работы СХД.

Так же надо помнить о том, что Windows оперирует блоками памяти по 4К и для оптимизации процесса записи данных на диск ОС формирует блоки по 1Mb (т.к. Windows считает, что использует локальный, выделенный ей одной диск, такие диски хороши при записи большых блоков). Однако, гипервизоры, получая данные от виртуальной машины сначала разбивают их на части, подходящие по размеру под сектор диска, а затем  пишут в рандомно выбраные сектора, что может вызвать падение производительности, особенно в RAID массивах с высоким административным пенальти.

В зависимости от процентного соотношения количества операций ввода/вывода СХД будет демонстрировать разную производительность. Давайте рассмотрим на конкретном примере.

Существуют формулы расчёта для различного рода сценариев, мы созьмём два:
  • Производительность полки при 85% операций записи и 15% чтения RAID 10 (или DP)
  • Производительность полки при 85% операций чтения и 15% записи в RAID 10 (DP)
Они помогут нам понять приближенные к максимуму значения.

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

~ TotalIOPs = 12 * 75 = 900 IOPs

Теперь рассмотрим первый сценарий, для этого нам необходимо выполнить рассчёт по формуле ниже:

WriteScenarioIOPs = ((TotalIOPs * 0,85)/ (RAIDPenalty)) + (TotalIOPs * 0.15)

итого получаем WriteScenarioIOPs  ((900 * 0,85)/ (2)) + (900 * 0.15) = 517,5 IOPs пиковой нагрузки.

А для второго сценария ReadScenarioIOPs мы изменим проценты, а формула прежняя:

ReadScenarioIOPs = ((900 * 0,15)/ (2)) + (900 * 0.85) = 832,5 IOPs

В итоге мы видим, что СХД с суммарной производительностью в 900 IOPs выдаёт 517,5 IOPs при активной записи и 832,5 при активном чтении. Замечу, что при RAID 5 результаты были бы минимум в двое ниже для сценария записи.

Пример: Quick Migration 12 виртуальных машин, используемых для тестовых целей, с одного узла кластера на другой.

При загрузке сетевого адаптера 1 Gbit/sec  iSCSI на 50-55% максиму, миграция съела в пиковую нагрузку 1000 - 1100 IOPs/sec (к сожалению со скриншотом поторопился:)) но в среднем варьировалась от 550 до 780 IOPs/sec.


При этом  производительность СХД реально составляла ~500 - 670 IOPs в секунду (тут есть погрешность). Посему процесс миграции происходил достаточно долго (более 3-х минут). Естественно, что при высокой загрузке виртуальных машин этот процесс мог бы растянуться на большее время.

Мы можем скоректировать производительность СХД, получив количество необходимых дополнительных дисков, зная количство необходимых IOPs.

Для этого надо:

DisksRequired = ((IOPs%Read + (IOPs%Write * RAIDPenalty))/IOPsPerDisk

IOPs%Read = количество планируемых пиковых операций чтения
IOPs%Write = количество планируемых пиковых операций записи
RAIDPenalty = административный пенальти
IOPsPerDisk = операций ввода/вывода, которые поддерживает выбранный носитель

Так же, мы можем понять сколько IOPs требуется конкретному приложению или системе исходя из следующих счётчиков производительности (Опять же не забываем про MAP, и максимальные значения показаний счётчиков):
 










Microsoft Windows Performance Counter

Industry Standard IOPS Name

Disk Transfers/sec

Total IOPS

Disk Reads/sec

Read IOPS

Disk Writes/sec

Write IOPS
Disk Queue-


Так же можно воспользоваться информацией от ПО управления HBA адаптерами или самой СХД.

Для отслеживания состояния CSV можно воспользоваться набором счетчиков


А для iSCSI, помимо базовой сетевой статистики интерфейса iSCSI, можно использовать следующий набор



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


Ссылки
http://en.wikipedia.org/wiki/Hard_disk_drive
http://en.wikipedia.org/wiki/Hard_disk_drive_performance_characteristics
http://en.wikipedia.org/wiki/Disk_buffer
http://en.wikipedia.org/wiki/Native_Command_Queuing
http://en.wikipedia.org/wiki/Tagged_Command_Queuing
http://en.wikipedia.org/wiki/IOPS
http://recoverymonkey.org/2012/07/26/an-explanation-of-iops-and-latency/
http://www.ssdfreaks.com/content/599/how-to-convert-mbps-to-iops-or-calculate-iops-from-mbs
http://habrahabr.ru/company/netapp/blog/102059/ - про FCoE и iSCSI плюсы и минусы
http://blogs.technet.com/b/askpfeplat/archive/2013/03/10/windows-server-2012-hyper-v-best-practices-in-easy-checklist-form.aspx
http://technet.microsoft.com/en-us/magazine/dd744830.aspx
http://www.shofkom.com/2010/04/15/moving-the-pagefile-to-another-drive-in-windows-server-2008/
http://theithollow.com/2012/03/understanding-raid-penalty/

Другие стати цикла
Проектирование ЦОД, виртуализация: как правильно обеспечить требования к производительности виртуальной машины
Проектирование ЦОД, виртуализация: как расчитать требования к аппаратному обеспечению для виртуализации инфраструктуры
Проектирование ЦОД, виртуализация: виртуализация "ЗА" и "ПРОТИВ"


Подборка ресурсов по VDI (немного устаревшие, но полезные)


Atlantis Computing
http://www.atlantiscomputing.com/win7iops  
Citrix Virtual Desktop Resource allocation
http://community.citrix.com/display/ocb/2010/11/12/Virtual+Desktop+Resource+Allocation  
IOMeter
http://www.iometer.org/  
WinSAT
http://technet.microsoft.com/en-us/library/cc742157(WS.10).aspx  
Performance Analysis of Logs (PAL) Tool
http://pal.codeplex.com/  
Win7 perfmon

http://technet.microsoft.com/en-gb/library/cc749249.aspx  
Logman

http://technet.microsoft.com/en-us/library/cc788121(WS.10).aspx  
ESXTop

http://communities.vmware.com/docs/DOC-5490 http://www.yellow-bricks.com/esxtop/  
ESX Storage Queues and Performance

http://communities.vmware.com/docs/DOC-6490  
XenServer Storage

http://support.citrix.com/article/ctx119088  
Understanding Memory Resource Management in VMware ESX 4.1
http://www.vmware.com/files/pdf/techpaper/vsp_41_perf_memory_mgmt.pdf  
SSD performance

http://www.ssdperformanceblog.com/2010/07/free-space-and-write-performance/  
VDI for developers
http://ultrasub.nl/2011/05/05/vdi-and-iops/