VMware объявила о старте программы vExpert в этом году.
Напомню, что vExpert - это не техническое звание как VCP и не требует каких-либо экзаменов. Звание vExpert присуждается за вклад в развитие сообщества блоггерам, авторам книг, лидерам VMware User Group, спикерам и организаторам мероприятий, лидерам форумов - иными словами всем тем, кто тратит свое время и делится своими знаниями с сообществом.
VMware vExpert'ы получают доступ к бетам продуктов, бесплатный доступ к контенту vmworld.com, доступ к закрытому форуму vExpert, лицензиям. В прошлом году звание vExpert получили около 350 человек, из них 6 в России и СНГ.
Вот здесь вы можете заявить свою активность в сообществе, либо номинировать того, кто, по вашему мнению, заслуживает звания vExpert за свою активность в 2010.
среда, 13 апреля 2011 г.
VMware User Group - Тбилиси, Грузия
Рад сообщить, что 22 апреля в Тбилиси пройдет первая встреча VMware User Group Georgia. Организатор мероприятия - Сандро Галдава с моей посильной помощью.
За поддержку спасибо компании EMC.
Регистрация здесь.
Приходите, будет интересно :)
За поддержку спасибо компании EMC.
Регистрация здесь.
Приходите, будет интересно :)
Ярлыки:
VMUG
суббота, 9 апреля 2011 г.
Бесплатная книга о защите данных в средах VMware
Компания Veeam сделала прекрасный подарок всему сообществу, выложив в открытый доступ книгу известного специалиста в области виртуальных сред VMware "Top 10 Best Practices for VMware Data Protection by VMware vExpert Eric Siebert".
Eric Siebert is an IT industry veteran, author and blogger with more than 25 years of experience, most recently specializing in server administration and virtualization. He is a very active member of the VMware VMTN support forums, where he's attained the elite Guru status by helping others with their virtualization-related challenges.
суббота, 26 марта 2011 г.
EMC Record Breaking Tour в Екатериннбурге и Новосибирске
Рад сообщить, что 5го апреля в Екатеринбурге и 7го апреля в Новосибирске состоятся семинары, посвященные новой линейке систем хранения данных EMC. Я на них присутствую, и даже не исключено, что выступаю. Приходите, будет интересно.
В любом случае буду готов ответить на ваши вопросы в кулуарах и рассказать про интеграцию СХД EMC и продуктов VMware.
P.S. и не откажусь от общения в неофициальном режиме за кружечкой пива после мероприятия :)
В любом случае буду готов ответить на ваши вопросы в кулуарах и рассказать про интеграцию СХД EMC и продуктов VMware.
P.S. и не откажусь от общения в неофициальном режиме за кружечкой пива после мероприятия :)
Ярлыки:
EMC
понедельник, 14 марта 2011 г.
Тонкие диски и фрагментация VMFS
На форуме VMTN часто поднимается миф о фрагментации VMFS и ее влиянии на дисковую производительность.
При создании тома VMFS вы выбираете размер блока форматирования (1, 2, 4 или 8 МБ). Этот размер блока влияет на то, как гипервизор будет выделять место для VMDK файлов. Для толстых дисков - размер блока, подлежащего заполнению нулями при первом доступе, для тонких - соотв. еще и размер блока для роста.
Так значит тонкие диски в сочетании с маленьким размером блока приведут к фрагментации? Да, это более чем возможно. Однако, вопрос должен звучать: а приведет ли это к снижению производительности? И ответ - нет. Прежде всего, размер блока форматирования VMFS не имеет никакого отношения к вводу-выводу гостевой ОС. Скажем, у вас обычная ВМ с Windows и эта ВМ читает и пишет блоками по 8кБ на томе с 1МБ блоками. Гипервизор не будет читать блоками по 1 МБ, поскольку это вызовет серьезную деградацию общей производительности. Нет, гипервизор передаст СХД запрос гостевой ОС, и СХД в свою очередь будет действовать в соответствии с собственными настройками. Вероятно люди беспокоятся о том, что фрагментации повлияет на последовательные чтение / запись, но подумайте секунду-две. О каком последовательном вводе-выводе мы говорим, если смотреть со стороны СХД? Множество хостов, на каждом из которых не одна ВМ, обращающихся к целой куче виртуальных дисков, размазанных по один Ньютон знает какому количеству шпинделей. Последовательный ввод-вывод вдруг оказывается не таким уж последовательным, не так ли?
Оригинал: Duncan Epping (yellow-bricks.com)
При создании тома VMFS вы выбираете размер блока форматирования (1, 2, 4 или 8 МБ). Этот размер блока влияет на то, как гипервизор будет выделять место для VMDK файлов. Для толстых дисков - размер блока, подлежащего заполнению нулями при первом доступе, для тонких - соотв. еще и размер блока для роста.
Так значит тонкие диски в сочетании с маленьким размером блока приведут к фрагментации? Да, это более чем возможно. Однако, вопрос должен звучать: а приведет ли это к снижению производительности? И ответ - нет. Прежде всего, размер блока форматирования VMFS не имеет никакого отношения к вводу-выводу гостевой ОС. Скажем, у вас обычная ВМ с Windows и эта ВМ читает и пишет блоками по 8кБ на томе с 1МБ блоками. Гипервизор не будет читать блоками по 1 МБ, поскольку это вызовет серьезную деградацию общей производительности. Нет, гипервизор передаст СХД запрос гостевой ОС, и СХД в свою очередь будет действовать в соответствии с собственными настройками. Вероятно люди беспокоятся о том, что фрагментации повлияет на последовательные чтение / запись, но подумайте секунду-две. О каком последовательном вводе-выводе мы говорим, если смотреть со стороны СХД? Множество хостов, на каждом из которых не одна ВМ, обращающихся к целой куче виртуальных дисков, размазанных по один Ньютон знает какому количеству шпинделей. Последовательный ввод-вывод вдруг оказывается не таким уж последовательным, не так ли?
Оригинал: Duncan Epping (yellow-bricks.com)
Ярлыки:
disk
суббота, 19 февраля 2011 г.
Виртуализация остановилась?
Scott Lowe нашел интересное мнение, опубликованное на InfoWorld.com. Цитирую (в моем переводе):
Правда ли она остановилась? Что же мешает предприятиям преодолеть рубеж в 18%? В комментариях к посту набралось достаточное количество интересных мнений, я их приведу:
Основная причина: Серверная виртуализация остановилась. Независимые исследователи и вендоры публикуют цифры, красноречиво говорящие, что хотя большинство крупных предприятий присматриваются к виртуализации, всерьез они ей так и не занялись.
Правда ли она остановилась? Что же мешает предприятиям преодолеть рубеж в 18%? В комментариях к посту набралось достаточное количество интересных мнений, я их приведу:
Ярлыки:
evangelism,
virtualization
Влияние различных размеров блока VMFS
На одном из форумов VMTN написали о неожиданном влиянии единого размера блока для всех томов VMFS. Пользователь произвел обнуление неиспользуемого пространства, чтобы диски скомпрессировались при Storage vMotion. Сюрпризом стало то, что диски остались того-же самого размера и после Storage vMotion.
После нескольких тестов было обнаружено, что при Storage vMotion между массивами, или между датасторами с различными размерами блока VMFS диски компрессировались. Почему?
Ответ прост: в этом случае используется другой datamover (модуль перемещения данных). Поскольку вам это мало о чем говорит, объясню какие бывают datamover'ы:

Так в чем же проблема? А проблема в одной маленькой строке текста в VAAI FAQ:
Как только выбирается датастор с другим размером блока, или датастор на другом массиве - гипервизор переключается на fsdm. Одно из немногих преимуществ этого datamover'а в том, что он "съедает" нули. В то время как fs3dm, вне зависимости от software / hardware offload, этого не делает и копирует блоки целиком.
Источник: Duncan Epping (yellow-bricks.com)
После нескольких тестов было обнаружено, что при Storage vMotion между массивами, или между датасторами с различными размерами блока VMFS диски компрессировались. Почему?
Ответ прост: в этом случае используется другой datamover (модуль перемещения данных). Поскольку вам это мало о чем говорит, объясню какие бывают datamover'ы:
- fsdm - самый старый datamover, с минимумом функций и самый медленный, поскольку данные проходят по всему стеку.
- fs3dm - был включен в состав vSphere 4.0 и содержал некоторые значительные изменения, позволяющие данным проходить не все уровни стека.
- fs3dm – hardware offload – datamover с поддержкой VAAI, аппаратной интеграции операций ввода/вывода с массивом. Появился в vSphere 4.1, имеет максимальную производительность и минимальные накладные расходы.

Так в чем же проблема? А проблема в одной маленькой строке текста в VAAI FAQ:
- The source and destination VMFS volumes have different block sizes
Как только выбирается датастор с другим размером блока, или датастор на другом массиве - гипервизор переключается на fsdm. Одно из немногих преимуществ этого datamover'а в том, что он "съедает" нули. В то время как fs3dm, вне зависимости от software / hardware offload, этого не делает и копирует блоки целиком.
Источник: Duncan Epping (yellow-bricks.com)
Подписаться на:
Сообщения (Atom)
