О vCenter Server.
Duncan Epping дает ссылку на видео по установке и проверке работоспособности vCenter Heartbeat.
Виртуальные машины.
Duncan Epping рассказывает про параметр “HaltingIdleMsecPenalty” для развертывания VDI.
Александр Самойленко рассказывает про изменение настроек VMware Tools в vSphere 5.1.
Александр Самойленко подробно рассказывает про технологическое превью продукта по доступу через PCoIP к RDS.
Александр Самойленко рассказывает о выходе спецификации стандарта OVF 2.0.
Системы хранения данных.
Duncan Epping рассказывает про размер задержек при организации метро-кластера СХД.
Frank Denneman рассказывает про то, чем руководствуется Storage DRS, когда размещает новую ВМ.
Jason Boche рассказывает про трудности использования “тонких” дисков у виртуальных машин VMware.
Роман Хмелевский рассказывает про утилиту fio для тестирования производительности дисков.
Шикарная статья на Хабре про тестирование производительности.
Виртуальные сети.
Frank Denneman рассказывает, почему при vMotion может использоваться VMKernel без флага vMotion.
Scott Lowe рассказывает про интеграцию RHEL и Open Switch (аналог Distributed Switch от VMware).
Андрей Коновалов рассказывает о нюансе использования Enhanced vMotion в vSphere 5.1.
Александр Самойленко рассказывает об анонсе распределенного коммутатора от NEC для Hyper-V.
Физические сервера.
Александр Самойленко делится секретом по подключению флешки в консоль ESXi5.1.
Прочие новости.
Chad Sakac делится размышлениями о том, что же выбрать: SRM или HA/DRS Stretched cluster.
Eric Sloof делится ссылкой, по которой дают бесплатную двухсокетную NFR-лицензию Nakivo Backup and Replication v2 для VCP, VExpert, VCI и членов VMUG-тусовки.
Спасибо за ссылку на хабростатью, шикарно и актуально.
Единственное что – кто-то из камрадов может объяснить “на пальцах” – почему при увеличении очереди увеличивается латентность? Разве приложению не все равно – ждать, пока его запрос исполнится в очереди, или ждать постановки в эту самую очередь?
Мне кажется, что это связано со следующим:
пока диски не нагружены, они обслуживают запросы быстро (то есть немного операций ввода/вывода и быстрое время отклика). Рост очередей значит, что повышается загрузка диска (точнее приближается к 100%), а следовательно, больше временных потерь из-за перемещения головок диска. Как следствие растет количество операций ввода/вывода, но растет и время отклика.
За 100% загрузку диска примем то, что диск 100% времени обслуживает чьи-то запросы.
Гм.. А разве процент временных потерь на перемещение головок диска (Random R/W же ведь!) как-то корелирует с уровнем его загрузки?
При случайном доступе (и без учета кэша) – да.
Представьте сами, у вас есть, допустим 10 случайных чтений с диска или 40 случайных чтений.
Во втором случае расходов на позиционирование головок (да и на саму операцию чтения) будет в несколько раз больше (~3-4).
В общем случае – пожалуй, где-то так и будет.
Но в статье берется именно случай worst case – кэш пробит, головки максимально ходят туда-сюда..
Я невеликий специалист именно в SAN, и в моем понимании увеличение очереди с 32 до 64 (а механика диска утилизовалась на 100% на уровне, ДОПУСТИМ, уже при 20 запросах в очереди) – то же самое, что увеличение размера словаля в архиваторах, шанс удачного выполнения команд должен только возрастать..
А по данным автора – все получается только хуже.