По многочисленным просьбам рассказываю что такое vShield Zones.
vShield Zones - это система файрволлов на каждом ESX + управляющая консоль. Файрволлы (vShield), как и консоль (vShield Manager), являются просто виртуальными машинами.
Принцип работы очень прост, у каждой vShield три сетевых интерфейса: mgmt, unprot и prot, которые подключены в соотв. портгруппы. Для коммуникации с vShield Manager используется mgmt интерфейс, обладающий собственным IP, unprot ловит все пакеты, проходящие через vSwitch, а после обработки пакеты отдаются во второй vSwitch (не имеющий физических аплинков) через prot интерфейс. В данном случае VMware не стала изобретать велосипед и просто купила компанию, специализирующуюся на таких решениях - BlueLane.
пятница, 29 мая 2009 г.
четверг, 28 мая 2009 г.
Сколько ВМ можно разместить на одном хосте?
Duncan Epping по традиции бьет не в бровь, а в глаз.
"Что, если я спрошу вас, какое максимальное количество ВМ можно разместить на одном хосте с vSphere?
Держу пари, что ответ будет 320 ВМ. Разумеется, ответ, основанный на "virtual machines per host" со страницы 5 "Configurations Maximum for vSphere".
Но будет ли он правильным? Нет, не будет. Правильный ответ: когда как. Зависит от того, используете вы HA или нет. Для HA кластера действуют иные ограничения (стр. 7):
Это очень серьезные ограничения, и не стоит о них забывать, разрабатывая проект виртуальной инфраструктуры. Вышеуказанные цифры затрагивают практически все, от размера кластера вплоть до выбора оборудования."
"Что, если я спрошу вас, какое максимальное количество ВМ можно разместить на одном хосте с vSphere?
Держу пари, что ответ будет 320 ВМ. Разумеется, ответ, основанный на "virtual machines per host" со страницы 5 "Configurations Maximum for vSphere".
Но будет ли он правильным? Нет, не будет. Правильный ответ: когда как. Зависит от того, используете вы HA или нет. Для HA кластера действуют иные ограничения (стр. 7):
* Максимум 32 хоста в HA кластере.
* Максимум 1280 ВМ в кластере.
* Максимум 100 ВМ на хост.
* Если количество хостов в кластере более 8, то максимум 40 ВМ на хост.
Это очень серьезные ограничения, и не стоит о них забывать, разрабатывая проект виртуальной инфраструктуры. Вышеуказанные цифры затрагивают практически все, от размера кластера вплоть до выбора оборудования."
vShield: не поднимается сеть
Первые грабли с vShield на ESX4.0 - не поднимается и не конфигурируется сеть ни на vShield Manager, ни на vShield машинах.
Лечение: после импорта appliance в инфраструктуру сменить сетевые адаптеры машин с Flexible на, например, VMXNET3.
Лечение: после импорта appliance в инфраструктуру сменить сетевые адаптеры машин с Flexible на, например, VMXNET3.
View 3.1 released
Что нового в View Manager 3.1
* Улучшения производительности - логин теперь происходит быстрее и меньше загружает сервер.
* Автоматизированный бэкап данных LDAP и View Composer Database - теперь можно настроитть автоматическое резервное копирование данных LDAP и базы данных View Composer из View Administrator.
* Информация о клиенте - информация об устройстве, с которого производится подключнение, теперь доступна в качестве ключей реестра. Это позволяет создавать скрипты для автоматического подключения к локальным принтерам или использовать 3rd party утилиты. Информация включает в себя название устройства, IP и MAC адреса устройства.
* Улучшенное логирование - отладочные логи включены по умолчанию. Логирование было улчшено для предоставления более информативных сообщений с минимальным влияением на загрузку.
* Улучшены мастеры редактирования десктопов - улучшенные мастеры редактирования повзволяют быстрее и удобнее редактировать существующие пулы десктопов.
* Улучшения USB - View 3.1 предлагает более надежную поддержку большего количества устройств с уменьшенным потреблением трафика. Теперь используются отделный TCP/IP поток.
* Multimedia Redirection (MMR) для Windows Vista - MMR теперь поддерживается для Windows Vista. Технология MMR доставяет мультимедиа поток напрямую на клиентское устройство вместо декодирования и отображения его через стандартный RDP. Это позволяет просматривать видео в полном качестве.
* Уменьшение потребления трафика для Adobe Flash.
* Поддержка различных протоколов - View Client теперь поддерживает HP Remote Graphics Software (RGS) как протокол отображения при подключении к HP Blade PC, рабочим станциям HP и Blade рабочим станциями HP. Подключением иуправляет брокер View Manager. HP RGS - протокол отображения HP, позволяющий пользователю подключаться к рабочему столу удаленного устройства по локальной сети. VMware View 3.1 поддерживает HP RGS версии 5.2.5. VMware не включает ПО и лицензии для HP RGS вместе с View 3.1.
* Улучшения производительности - логин теперь происходит быстрее и меньше загружает сервер.
* Автоматизированный бэкап данных LDAP и View Composer Database - теперь можно настроитть автоматическое резервное копирование данных LDAP и базы данных View Composer из View Administrator.
* Информация о клиенте - информация об устройстве, с которого производится подключнение, теперь доступна в качестве ключей реестра. Это позволяет создавать скрипты для автоматического подключения к локальным принтерам или использовать 3rd party утилиты. Информация включает в себя название устройства, IP и MAC адреса устройства.
* Улучшенное логирование - отладочные логи включены по умолчанию. Логирование было улчшено для предоставления более информативных сообщений с минимальным влияением на загрузку.
* Улучшены мастеры редактирования десктопов - улучшенные мастеры редактирования повзволяют быстрее и удобнее редактировать существующие пулы десктопов.
* Улучшения USB - View 3.1 предлагает более надежную поддержку большего количества устройств с уменьшенным потреблением трафика. Теперь используются отделный TCP/IP поток.
* Multimedia Redirection (MMR) для Windows Vista - MMR теперь поддерживается для Windows Vista. Технология MMR доставяет мультимедиа поток напрямую на клиентское устройство вместо декодирования и отображения его через стандартный RDP. Это позволяет просматривать видео в полном качестве.
* Уменьшение потребления трафика для Adobe Flash.
* Поддержка различных протоколов - View Client теперь поддерживает HP Remote Graphics Software (RGS) как протокол отображения при подключении к HP Blade PC, рабочим станциям HP и Blade рабочим станциями HP. Подключением иуправляет брокер View Manager. HP RGS - протокол отображения HP, позволяющий пользователю подключаться к рабочему столу удаленного устройства по локальной сети. VMware View 3.1 поддерживает HP RGS версии 5.2.5. VMware не включает ПО и лицензии для HP RGS вместе с View 3.1.
среда, 27 мая 2009 г.
Online VMware User Group
Alan Renouf создал Online VMware User Group. На текущий момент она неофициальная, но уже решается вопрос о ее официальном статусе. 1 июня состоится первая встреча в пространстве Live Meeting :)
Вебинар также будет записан для тех, кто не сможет присутствовать.
Дата: 1 июня 2009
Время: 08:00 PM GMT - 00:00 по московскому
URL: https://www.livemeeting.com/cc/winserver_usergroup/join?id=QP5K5Q&role=attend&pw=8%5E-%5CzqX
Meeting ID: QP5K5Q
Attendee Entry Code: 8^-\zqX
Регистрация: http://www.clicktoattend.com/?id=138358
Upd: уточню - начало в 00:00 2го июня из-за разницы во времени :)
Introduction
Presentation and Demonstration of The Virtualization EcoShell Initiative by Scott Herold
Virtual Coffee break (bring your own coffee)
Overview and Demonstration of vSphere new features by a VMware Employee
Finish and details of next Unofficial Online VMUG
Вебинар также будет записан для тех, кто не сможет присутствовать.
Дата: 1 июня 2009
Время: 08:00 PM GMT - 00:00 по московскому
URL: https://www.livemeeting.com/cc/winserver_usergroup/join?id=QP5K5Q&role=attend&pw=8%5E-%5CzqX
Meeting ID: QP5K5Q
Attendee Entry Code: 8^-\zqX
Регистрация: http://www.clicktoattend.com/?id=138358
Upd: уточню - начало в 00:00 2го июня из-за разницы во времени :)
понедельник, 25 мая 2009 г.
ESX 4 под ESX 3
Если у вас не хватает железа на то, чтобы посмотреть на ESX4 - рано расстраиваться.
Провел эксперимент - поставил ESXi 4 (GA) в ВМ под ESXi 3 (3.5u4) и наоборот. ВМ с ESXi 4 на тройке моментально завелась. А вот тройка на четверке, хоть и поставилась, но уже полтора часа пытается загрузиться.
Провел эксперимент - поставил ESXi 4 (GA) в ВМ под ESXi 3 (3.5u4) и наоборот. ВМ с ESXi 4 на тройке моментально завелась. А вот тройка на четверке, хоть и поставилась, но уже полтора часа пытается загрузиться.
Everything is amazing, but nobody's happy.
Не успела VMware выпустить vSphere с технологией FT, сразу же появились недовольные. Почему всего для одного процессора? Непорядок! Срочно бежать и делать FT для SMP!
Ответ сотрудника VMware на форуме: "Для решения проблему синхронизации двух (однопроцессорных) ВМ потребовались сотни и тысячи рабочих часов самых опытных инженеров и ведущих разработчиков. Решение данной задачи для многопроцессорных машин потребует значительно большего количества времени и, возможно, даже иного подхода."
В тему этого всего (на английский языке):
"Как мир успел ему задолжать что-то, о существовании чего он сам узнал лишь 10 секунд назад?!"
Ответ сотрудника VMware на форуме: "Для решения проблему синхронизации двух (однопроцессорных) ВМ потребовались сотни и тысячи рабочих часов самых опытных инженеров и ведущих разработчиков. Решение данной задачи для многопроцессорных машин потребует значительно большего количества времени и, возможно, даже иного подхода."
В тему этого всего (на английский языке):
"Как мир успел ему задолжать что-то, о существовании чего он сам узнал лишь 10 секунд назад?!"
пятница, 22 мая 2009 г.
FT & Split Brain
Dave Lawrence (VMware) рассказал как именно FT борется со Split Brain.
Что делает Fault Tolerance для предотвращения Split Brain ситуаций, когда первичная и теневая ВМ становятся изолированными?
Fault Tolerance (FT) использует файл на диске с номером поколения ВМ. При создании FT машины (включении FT) создается файл на разделяемом хранилище с именем generation.N, где N - счетчик. При подключении теневой машины к первичной, первичная сообщает теневой текущий номер поколения. Как только первичная или теневая машина обнаруживает сбой во второй половине, она пытается переименовать файл в generation.N+1. При успехе машина переключается в режим первичной (или остается первичной) и дает команду на построение теневой машины, чтобы остаться защищенной от сбоев. Если же переименование файла не удалось, значит его уже переименовала вторая машина в паре и эта машина выключается.
Таким образом дисковая система служит для предовращения переключения обеих машин в режим первичной и соотв. Split Brain ситуаций.
Что делает Fault Tolerance для предотвращения Split Brain ситуаций, когда первичная и теневая ВМ становятся изолированными?
Fault Tolerance (FT) использует файл на диске с номером поколения ВМ. При создании FT машины (включении FT) создается файл на разделяемом хранилище с именем generation.N, где N - счетчик. При подключении теневой машины к первичной, первичная сообщает теневой текущий номер поколения. Как только первичная или теневая машина обнаруживает сбой во второй половине, она пытается переименовать файл в generation.N+1. При успехе машина переключается в режим первичной (или остается первичной) и дает команду на построение теневой машины, чтобы остаться защищенной от сбоев. Если же переименование файла не удалось, значит его уже переименовала вторая машина в паре и эта машина выключается.
Таким образом дисковая система служит для предовращения переключения обеих машин в режим первичной и соотв. Split Brain ситуаций.
3D в виртуальных машинах
Встретилось на просторах инета.
Потрясающий прорыв! Если не считать того, что Parallels поддерживает аппаратное 3D ускорение в Parallels Workstation Extreme на рабочих станциях HP Z800.
Ну и VMware поддерживает аппаратное ускорение для виртуальных машин в VMware Workstation 6.5.
Как говорится, мануалы надо читать, а не курить. Ну и желательно, конечно, почитать еще мануалы и спеки на то, с чем сравниваешь.
Ни у VMWARE ни у Parallels нет того предложили чуваки из SUN! VirtualBox начиная с версии 2.2.2. поддерживает софтверную 3Д акселерацию!
Потрясающий прорыв! Если не считать того, что Parallels поддерживает аппаратное 3D ускорение в Parallels Workstation Extreme на рабочих станциях HP Z800.
Ну и VMware поддерживает аппаратное ускорение для виртуальных машин в VMware Workstation 6.5.
Как говорится, мануалы надо читать, а не курить. Ну и желательно, конечно, почитать еще мануалы и спеки на то, с чем сравниваешь.
VI 3.5 -> vSphere 4 upgrade
Краткая сводка с фронта:
- ESXi Embedded и ESX успешно проапгрейдились с 3.5u4 до 4.0
- апгрейд прошел без даунтайма, VMotion между 3.5u4 и 4.0 работает
- кластер из смешанных хостов 3.5 и 4.0 прекрасно работает
Тестовая зона успешно переведена на 4.0
- ESXi Embedded и ESX успешно проапгрейдились с 3.5u4 до 4.0
- апгрейд прошел без даунтайма, VMotion между 3.5u4 и 4.0 работает
- кластер из смешанных хостов 3.5 и 4.0 прекрасно работает
Тестовая зона успешно переведена на 4.0
четверг, 21 мая 2009 г.
среда, 20 мая 2009 г.
Летняя встреча VMware User Group Russia
Начинается подготовка к летней встрече и поэтому вопрос всем читателям, планирующим там оказаться:
1) доклады на какие темы вы хотите услышать на встрече?
2) готовы ли вы подготовить доклад и его прочитать? Если да, то на какую тему?
1) доклады на какие темы вы хотите услышать на встрече?
2) готовы ли вы подготовить доклад и его прочитать? Если да, то на какую тему?
USB в виртуальной машине
Are USB devices supported in a VM in ESX 4?
• Yes, but only devices attached to a host can be presented to a VM. Devices attached to a machine running the vSphere Client cannot be redirected and presented inside a VM by ESX/ESXi alone. (USB redirection can be found in VMware View and is supported through RDP.)
• USB support requires installation of VMware Tools.
Поддерживаются ли USB устройства в VM в ESX 4?
• Да, но только устройства, подключенные к хосту, могут быть презентованы виртуальной машине. Устройства, подключенные к машине, на которой запущен vSphere клиент не могут быть перенаправлены и подключены к виртуальной машине напрямую. (Однако перенаправление USB есть в VMware View и поддерживается протоколом RDP)
• Поддержка USB требует установки VMware Tools.
Информация неофициальная, но с учетом того, что в виртуальных машинах появились USB контроллеры, похожа на правду. Увы, проверить не могу. Ждем завтрашнего релиза :)
Thnx to Mr. Nobody
• Yes, but only devices attached to a host can be presented to a VM. Devices attached to a machine running the vSphere Client cannot be redirected and presented inside a VM by ESX/ESXi alone. (USB redirection can be found in VMware View and is supported through RDP.)
• USB support requires installation of VMware Tools.
Поддерживаются ли USB устройства в VM в ESX 4?
• Да, но только устройства, подключенные к хосту, могут быть презентованы виртуальной машине. Устройства, подключенные к машине, на которой запущен vSphere клиент не могут быть перенаправлены и подключены к виртуальной машине напрямую. (Однако перенаправление USB есть в VMware View и поддерживается протоколом RDP)
• Поддержка USB требует установки VMware Tools.
Информация неофициальная, но с учетом того, что в виртуальных машинах появились USB контроллеры, похожа на правду. Увы, проверить не могу. Ждем завтрашнего релиза :)
Thnx to Mr. Nobody
вторник, 19 мая 2009 г.
Куда уходит место на дисках?
Одна из проблемных областей администраторов платформ виртуализации - куда девается место на дисках?
А все просто.
Overprovisioning
Администраторы забывают, что они больше не работают с железками и выделяют дискового пространства сразу от души, на вырост. Оно и понятно - если купить сервер с дисками, скажем, по 36, то очень скоро место может просто кончиться и единственный вариант - выкидывать эти диски и покупать новые, после чего переносить данные.
В виртуальной среде и конкретно VMware VI диски виртуальных машин можно увеличивать онлайн. Не хватает 8ГБ - на тебе еще 2, до 10. Все ограничивается только необходимостью работы с файловой системой и расширением разделов. Увеличить диски можно всегда, а вот уменьшить - нет, увы.
Каждый гигабайт, который выделен машине без необходимости, "на вырост", лежит мертвым грузом. И его нельзя использовать для других машин. Каждый гигабайт, который выделен "на вырост" без необходимости, будет лежать мертвым грузом очень долго, увеличивая расходы на СХД.
Неразумное использование снапшотов
Некоторые администраторы используют снапшоты не в качестве временной меры, создания точки отката при внесении изменений, а на постоянной основе. Делаем что-то - снапшот. И не удаляем. А вдруг понадобится? Получается как в анекдоте про дохлую кошку: "Не пригодилась".
Снапшоты в абсолютном большинстве случаев не нужны больше, чем на неделю. Патчим систему? Снапшот. Патчи работают, все ОК? Удаляем снапшот.
Практически слышу сразу "А если что-то случится после, то куда откатываться?". Господа, а бэкапы на что? Снапшот - это _быстрый_ откат, это не средство резервного копирования.
Более того, если объединить постоянное использование снапшотов и overprovisioning - вообще грустная картина. Поставили голую систему (пусть будет Windows 2003) на диск в 20ГБ, снапшот. Поставили патч - снапшот, поставили еще что-то - снапшот. Да, у ВМ 2ГБ памяти. Итого имеем, скажем, 5 снапшотов со средней дельтой в 1,5ГБ, и финальное использование диска в 30% (6ГБ). Что это значит на практике? А на практике это значит, что 12ГБ дискового пространства потрачены впустую только на overprovisioning. Каждый снапшот занимает 2ГБ (снимок RAM) + 1,5ГБ (дельта) = 3,5*5 = 17,5ГБ. Итого, ВМ, которой требуется всего 6ГБ впустую расходует почти 30ГБ дискового пространства СХД. Почему, кстати, 12 - потому что чистое использование диска 6ГБ, но 2ГБ свободными оставить стоит хотя бы из соображений дефрагментации (Windows рекомендует не менее 15% диска) и небольшого(!) запаса рабочего места.
В этом случае машина нам обошлась в 37,5/8 = 4,7 раза дороже по статье СХД, чем должна была. (написано по мотивам реальной ВМ)
Неразумное использование снапшотов также и не дает увеличить диск для ВМ, если место на нем кончается - все снапшоты сначала надо будет накатить.
Постоянно растущие снапшоты снижают быстродействие и дисковой системы для разделяемых хранилищ из-за постоянных блокировок метаданных.
Поэтому:
1) В случае с ВМ заповедь "много не мало" работает в обратную сторону. Семь раз подумай, прежде чем добавить место, отрезать уже не получится.
2) Не храните снапшоты без крайней необходимости, пользуетесь бэкапами.
А все просто.
Overprovisioning
Администраторы забывают, что они больше не работают с железками и выделяют дискового пространства сразу от души, на вырост. Оно и понятно - если купить сервер с дисками, скажем, по 36, то очень скоро место может просто кончиться и единственный вариант - выкидывать эти диски и покупать новые, после чего переносить данные.
В виртуальной среде и конкретно VMware VI диски виртуальных машин можно увеличивать онлайн. Не хватает 8ГБ - на тебе еще 2, до 10. Все ограничивается только необходимостью работы с файловой системой и расширением разделов. Увеличить диски можно всегда, а вот уменьшить - нет, увы.
Каждый гигабайт, который выделен машине без необходимости, "на вырост", лежит мертвым грузом. И его нельзя использовать для других машин. Каждый гигабайт, который выделен "на вырост" без необходимости, будет лежать мертвым грузом очень долго, увеличивая расходы на СХД.
Неразумное использование снапшотов
Некоторые администраторы используют снапшоты не в качестве временной меры, создания точки отката при внесении изменений, а на постоянной основе. Делаем что-то - снапшот. И не удаляем. А вдруг понадобится? Получается как в анекдоте про дохлую кошку: "Не пригодилась".
Снапшоты в абсолютном большинстве случаев не нужны больше, чем на неделю. Патчим систему? Снапшот. Патчи работают, все ОК? Удаляем снапшот.
Практически слышу сразу "А если что-то случится после, то куда откатываться?". Господа, а бэкапы на что? Снапшот - это _быстрый_ откат, это не средство резервного копирования.
Более того, если объединить постоянное использование снапшотов и overprovisioning - вообще грустная картина. Поставили голую систему (пусть будет Windows 2003) на диск в 20ГБ, снапшот. Поставили патч - снапшот, поставили еще что-то - снапшот. Да, у ВМ 2ГБ памяти. Итого имеем, скажем, 5 снапшотов со средней дельтой в 1,5ГБ, и финальное использование диска в 30% (6ГБ). Что это значит на практике? А на практике это значит, что 12ГБ дискового пространства потрачены впустую только на overprovisioning. Каждый снапшот занимает 2ГБ (снимок RAM) + 1,5ГБ (дельта) = 3,5*5 = 17,5ГБ. Итого, ВМ, которой требуется всего 6ГБ впустую расходует почти 30ГБ дискового пространства СХД. Почему, кстати, 12 - потому что чистое использование диска 6ГБ, но 2ГБ свободными оставить стоит хотя бы из соображений дефрагментации (Windows рекомендует не менее 15% диска) и небольшого(!) запаса рабочего места.
В этом случае машина нам обошлась в 37,5/8 = 4,7 раза дороже по статье СХД, чем должна была. (написано по мотивам реальной ВМ)
Неразумное использование снапшотов также и не дает увеличить диск для ВМ, если место на нем кончается - все снапшоты сначала надо будет накатить.
Постоянно растущие снапшоты снижают быстродействие и дисковой системы для разделяемых хранилищ из-за постоянных блокировок метаданных.
Поэтому:
1) В случае с ВМ заповедь "много не мало" работает в обратную сторону. Семь раз подумай, прежде чем добавить место, отрезать уже не получится.
2) Не храните снапшоты без крайней необходимости, пользуетесь бэкапами.
ESX 4 может виртуализовать даже сам себя
Eric Gray (VCritical) поделился рецептом рекурсивной виртуализации ESX 4.
После инсталляции ESX 4 необходимо изменить настройки vSwitch на следующие:
Создайте новую ВМ следующей конфигурации (выберите "Custom")
Virtual Machine Version 7
Guest OS: Linux / Red Hat Enterprise Linux 5 (64-bit)
2 VCPUs, 2GB RAM
2 NICs - e1000
LSI Logic Parallel
Новый диск - разумного размера
После этого подключите в виртуальный CD-Rom ISO с ESX 4 и поставьте как гостевую ОС.
После установки добавьте новый виртуальный ESX к vCenter 4 и создайте новую ВМ.
Если не требуется запускать ВМ в этом виртуальном ESX, то здесь можно остановиться. При попытке запустить ВМ будет выдаваться следующее сообщение:
Чтобы обойти это, достаточно всего одной минуты. Выключите виртуальный ESX и измените настройки ВМ: Edit Settings; Options; Advanced / General / Configuration Parameters… ; Add Row
Name/Value: monitor_control.restrict_backdoor / TRUE
После инсталляции ESX 4 необходимо изменить настройки vSwitch на следующие:
Создайте новую ВМ следующей конфигурации (выберите "Custom")
После этого подключите в виртуальный CD-Rom ISO с ESX 4 и поставьте как гостевую ОС.
После установки добавьте новый виртуальный ESX к vCenter 4 и создайте новую ВМ.
Если не требуется запускать ВМ в этом виртуальном ESX, то здесь можно остановиться. При попытке запустить ВМ будет выдаваться следующее сообщение:
Чтобы обойти это, достаточно всего одной минуты. Выключите виртуальный ESX и измените настройки ВМ: Edit Settings; Options; Advanced / General / Configuration Parameters… ; Add Row
Name/Value: monitor_control.restrict_backdoor / TRUE
понедельник, 18 мая 2009 г.
Тема облаков раскрыта!
Хочу поделиться ссылкой на отличный ресурс, посвященный облакам.
Smart Cloud
И раскрывая тему облаков, более строгое определение их типов:
Software as a Service (SaaS) - Программное обеспечение как сервис.
Под данным определением понимается предоставление доступа к программам, запущенным на серверах, через веб-браузер. В качестве примера можно привести веб-интерфейс к серверам электронной почты, форумы, социальные сети (В Контакте, Одноклассники), фотоальбомы, а также программы, ранее доступные только посредством установки их на локальный компьютер. Известнейшим разработчиком офисных программ, использующих веб-браузер, является компания Google. Ее коллекция программ под названием Google Docs позволяет редактировать файлы и таблицы прямо в сети Интернет.
Platform as a Service (PaaS) - Платформа как сервис.
Если Вам нужна операционная система Линукс, или веб-сервер, или вы хотите построить свой продукт на основе систем управления базами данных Oracle или MySQL, Вам необязательно подбирать аппаратное обеспечение, устанавливать и настраивать программы. Услуга "Платформа как сервис" предоставляет возможность гибкого и широкого выбора настроенных под Ваши задачи виртуальных вычислительных ресурсов. Одним из примеров может служить доступ к виртуальному Windows XP с установленным на нем офисным пакетом.
Infrastructure as a Service (IaaS) - Инфраструктура как сервис
Услуга "Инфраструктура как Сервис" предназначается тем пользователям, которым нужны мощные вычислительные ресурсы. Последние, как правило, стоят больших денег - не только при покупке, но и в обслуживании. Виртуальная инфраструктура позволяет съэкономить на аппаратном обеспечении и на услугах IT (например, администрирование серверов, арендная плата за место, электричество итп). Также данная услуга расчитана на масштабируемость вычислительных ресурсов, например, количество оперативной памяти, процессоров, дискового пространства можно изменять буквально на лету. Одной из разновидностей IaaS стала услуга Data Storage as a Service (dSaaS) - Хранение данных как сервис. Самыми известными представителями IaaS и dSaaS на сегодняшний день являются Elastic Compute Cloud (EC2) и Simple Storage Service (S3) компании Amazon LLC.
http://smart-cloud.ru/faq/31-general/52--cloud-computing
Smart Cloud
И раскрывая тему облаков, более строгое определение их типов:
Software as a Service (SaaS) - Программное обеспечение как сервис.
Под данным определением понимается предоставление доступа к программам, запущенным на серверах, через веб-браузер. В качестве примера можно привести веб-интерфейс к серверам электронной почты, форумы, социальные сети (В Контакте, Одноклассники), фотоальбомы, а также программы, ранее доступные только посредством установки их на локальный компьютер. Известнейшим разработчиком офисных программ, использующих веб-браузер, является компания Google. Ее коллекция программ под названием Google Docs позволяет редактировать файлы и таблицы прямо в сети Интернет.
Platform as a Service (PaaS) - Платформа как сервис.
Если Вам нужна операционная система Линукс, или веб-сервер, или вы хотите построить свой продукт на основе систем управления базами данных Oracle или MySQL, Вам необязательно подбирать аппаратное обеспечение, устанавливать и настраивать программы. Услуга "Платформа как сервис" предоставляет возможность гибкого и широкого выбора настроенных под Ваши задачи виртуальных вычислительных ресурсов. Одним из примеров может служить доступ к виртуальному Windows XP с установленным на нем офисным пакетом.
Infrastructure as a Service (IaaS) - Инфраструктура как сервис
Услуга "Инфраструктура как Сервис" предназначается тем пользователям, которым нужны мощные вычислительные ресурсы. Последние, как правило, стоят больших денег - не только при покупке, но и в обслуживании. Виртуальная инфраструктура позволяет съэкономить на аппаратном обеспечении и на услугах IT (например, администрирование серверов, арендная плата за место, электричество итп). Также данная услуга расчитана на масштабируемость вычислительных ресурсов, например, количество оперативной памяти, процессоров, дискового пространства можно изменять буквально на лету. Одной из разновидностей IaaS стала услуга Data Storage as a Service (dSaaS) - Хранение данных как сервис. Самыми известными представителями IaaS и dSaaS на сегодняшний день являются Elastic Compute Cloud (EC2) и Simple Storage Service (S3) компании Amazon LLC.
http://smart-cloud.ru/faq/31-general/52--cloud-computing
пятница, 15 мая 2009 г.
четверг, 14 мая 2009 г.
FT & Snapshots
В качестве ответа на вопрос на сегодняшнем вебинаре по FT & HA.
Fault Tolerance не совместим со снапшотами и соотв. их не поддерживает.
Почему они несовместимы? Для FT обязательным требованием является thick диск, и даже не просто thick, а eagerzeroedthick, поскольку FT очень чувствительно относится к изменению метаданных. А снапшот виртуального диска представляет собой сам диск и растущий дельта файл, который как раз метаданные изменяет ровно так же, как и thin диск.
Поскольку прозвучал вопрос и про eagerzeroedthick - напомню разницу между ним и просто thick. Thick при создании полностью выделяет место в объеме самого диска, и при первом обращении к каждому блоку сначала его очищает. На практике это моментальное создание, а затем некоторое время низкая дисковая производительность (пока не будет обращений к большинству блоков). Eagerzeroedthick очищает весь диск при создании, поэтому создается такой диск довольно долго, но сразу же после создания выдает максимальные IOPS.
Fault Tolerance не совместим со снапшотами и соотв. их не поддерживает.
Required
Virtual Machines: Ensure that there is no user requirement to have
virtual machine snapshots since these are not supported for VMware
FT. Delete snapshots from existing virtual machines before protecting
with VMware FT.
http://www.vmware.com/files/pdf/vsphere-migration-prerequisites-checklist.pdf
Почему они несовместимы? Для FT обязательным требованием является thick диск, и даже не просто thick, а eagerzeroedthick, поскольку FT очень чувствительно относится к изменению метаданных. А снапшот виртуального диска представляет собой сам диск и растущий дельта файл, который как раз метаданные изменяет ровно так же, как и thin диск.
Поскольку прозвучал вопрос и про eagerzeroedthick - напомню разницу между ним и просто thick. Thick при создании полностью выделяет место в объеме самого диска, и при первом обращении к каждому блоку сначала его очищает. На практике это моментальное создание, а затем некоторое время низкая дисковая производительность (пока не будет обращений к большинству блоков). Eagerzeroedthick очищает весь диск при создании, поэтому создается такой диск довольно долго, но сразу же после создания выдает максимальные IOPS.
среда, 13 мая 2009 г.
Как устроен VMFS раздел
Понимание архитектуры VMFS очень важно для правильного обслуживания инфраструктуры Vmware. Когда журнал хранилища пестрит ошибками, необходимо точно оценить состояние VMFS-раздела и провести необходимые работы по исправлению ошибок.
Подробности об устройстве VMFS - здесь.
Oracle покупает Virtual Iron
Сегодня официально подтвердился слух о покупке Oracle компании Virtual Iron, имеющей самый коммерчески успешный продукт на базе Xen.
Таким образом на руках у Oracle оказываются сразу три Xen-based продукта: Oracle VM, Sun xVM и Virtual Iron. Очевидно, что чем-то придется жертвовать. Рискну предположить, что основой платформы виртуализации от Oracle станет Virtual Iron, в который в той или иной степени вольется остальное.
А что же касается Xen, то по факту остаются основными игроками на рынке Oracle и Citrix, возможно какое-то незначительное влияние окажет Novell.
RedHat ранее уже объявила об отказе от Xen в пользу KVM, Linux Foundation так же рекомендовали всем мэйнтейнерам дистрибутивов переход на KVM.
Таким образом на руках у Oracle оказываются сразу три Xen-based продукта: Oracle VM, Sun xVM и Virtual Iron. Очевидно, что чем-то придется жертвовать. Рискну предположить, что основой платформы виртуализации от Oracle станет Virtual Iron, в который в той или иной степени вольется остальное.
А что же касается Xen, то по факту остаются основными игроками на рынке Oracle и Citrix, возможно какое-то незначительное влияние окажет Novell.
RedHat ранее уже объявила об отказе от Xen в пользу KVM, Linux Foundation так же рекомендовали всем мэйнтейнерам дистрибутивов переход на KVM.
Облака - белогривые лошадки
Модный термин в последнее время, так что же это? Частично я уже писал об этом, но хочется вынести тему в отдельный пост и раскрыть шире.
Говоря академически, Облако - это уровень абстракции от физического оборудования до чистых ресурсов. Т.е. на уровне облака больше не говорится о физических интерфейсах и железках, речь идет лишь о мегагерцах просессорной мощности, мегабайтах памяти и дисков, мегабитах сетевого соединения. Нас не волнует физическая реализация, этим занимаются инженеры по инфраструктуре.
Облако - это тот уровень абстракции, который необходим для воплощения понятия computing as a service, он же utility computing. На облачном уровне у нас больше нет сервера1, сервера2 и т.д... У нас есть объединенные вычислительные ресурсы, которые мы можем как-то делить между задачами.
В принципе, облака можно разделить на два типа - облака для приложений и облака для машин. В чем же между ними разница?
Облака приложений предоставляют ресурсы приложениям, разработанным специальным образом для этого облака. Не нужно заботиться об ОС, и прочих инфраструктурных вопросах, только чистое прикладное приложение. Вся инфраструктура и ее поддержка лежит на специалистах. Пример облака приложений - Windows Azure.
Облака для машин предоставляют ресурсы виртуальным машинам, и по сути являются более низкоуровневыми облаками или в каком-то смысле менее облачными :)
Атомарная единица здесь не приложение, а виртуальная машина. На которую можно установить любую ОС и вообще обращаться как с обыкновенным сервером.
В чем же здесь облачность? В том, что нас снова не волнует на каком именно физическом сервере исполняется ВМ, степени загрузки физических процессоров и тому подобное. Мы заказали столько-то мегагерц мощности, и мегабайт памяти - мы их получим. Не хватает - добавим без долгих заказов новых процессоров или модулей памяти. Выгодное отличие от облаков приложений в том, что не требуется переписывать уже существующие приложения. Минус - необходимость администрирования дополнительных инфраструктурных слоев.
Простейший пример подобного облака - большой Fully automated DRS кластер ESX. Но при одном условии - каждая ВМ требует ресурсов, значительно меньших, чем ресурсы одного хоста. Как только уровень ресурсов становится сравним, облако рассеивается на отдельно стоящие хосты.
Облака - это не пустое понятие, у нас с вами уже есть в серверных свои собственные маленькие белогривые лошадки :)
Говоря академически, Облако - это уровень абстракции от физического оборудования до чистых ресурсов. Т.е. на уровне облака больше не говорится о физических интерфейсах и железках, речь идет лишь о мегагерцах просессорной мощности, мегабайтах памяти и дисков, мегабитах сетевого соединения. Нас не волнует физическая реализация, этим занимаются инженеры по инфраструктуре.
Облако - это тот уровень абстракции, который необходим для воплощения понятия computing as a service, он же utility computing. На облачном уровне у нас больше нет сервера1, сервера2 и т.д... У нас есть объединенные вычислительные ресурсы, которые мы можем как-то делить между задачами.
В принципе, облака можно разделить на два типа - облака для приложений и облака для машин. В чем же между ними разница?
Облака приложений предоставляют ресурсы приложениям, разработанным специальным образом для этого облака. Не нужно заботиться об ОС, и прочих инфраструктурных вопросах, только чистое прикладное приложение. Вся инфраструктура и ее поддержка лежит на специалистах. Пример облака приложений - Windows Azure.
Облака для машин предоставляют ресурсы виртуальным машинам, и по сути являются более низкоуровневыми облаками или в каком-то смысле менее облачными :)
Атомарная единица здесь не приложение, а виртуальная машина. На которую можно установить любую ОС и вообще обращаться как с обыкновенным сервером.
В чем же здесь облачность? В том, что нас снова не волнует на каком именно физическом сервере исполняется ВМ, степени загрузки физических процессоров и тому подобное. Мы заказали столько-то мегагерц мощности, и мегабайт памяти - мы их получим. Не хватает - добавим без долгих заказов новых процессоров или модулей памяти. Выгодное отличие от облаков приложений в том, что не требуется переписывать уже существующие приложения. Минус - необходимость администрирования дополнительных инфраструктурных слоев.
Простейший пример подобного облака - большой Fully automated DRS кластер ESX. Но при одном условии - каждая ВМ требует ресурсов, значительно меньших, чем ресурсы одного хоста. Как только уровень ресурсов становится сравним, облако рассеивается на отдельно стоящие хосты.
Облака - это не пустое понятие, у нас с вами уже есть в серверных свои собственные маленькие белогривые лошадки :)
вторник, 12 мая 2009 г.
В качестве полемики с сотрудниками MS
А конкретно с Алексеем Кибкало.
1. Наличие бОльшего количества обновлений и даже критических обновлений для ESX не говорит ни о чем, кроме бОльшего количества обновлений.
2. В обновления ESX включаются так же и обновления драйверов (!). Напомните пожалуйста, как там с обновлением драйверов у Hyper-V?
3. При наличии лицензии VMotion (Live Migration) даунтайма для сервисов при установке обновлений на хост нет вообще. Сравним с Hyper-V, у которого Live Migration только-только выйдет.
4. Обновления VMware выпускаются обычно сразу по несколько и ставятся за один раз, что автоматически опровергает расчеты количества перезагрузок.
Итого, вроде и цифры есть, а толку в них?
Интересна и реакция данного сотрудника Microsoft на вот этот пост у меня в блоге.
У меня возник вопрос: параноидальным MS-ненавистником назвали Stu (vinternals.com) или меня? И лично я не припомню никаких комментариев с цифрами, не говоря уже о том, чтобы я что-то удалял (за исключением спама).
Да и MS-ненавистником я не являюсь ни в какой мере, за исключением пожалуй, неприязни к многим методам маркетинга MS. И я рад тому, что в рунете есть возможность дискутировать на эту тему с НЕмаркетинговыми специалистами.
На данный момент известно 14 критических обновлений безопасности (сравним с 36 критическими и 31 обновлений безопасности для VMware ESX Server 3.5 за тот же срок), а всех исправлений к Windows Server 2008 на сегодня известно 41 (сравним с 148 исправлениями для VMware ESX Server 3.5). Очевидно, что большая часть новых обновлений включает в себя часть предыдущих, заменяя их. Однако, если их устанавливать их не все сегодня, а постепенно — сразу после выхода, то количество установок было было бы именно такое. Эти числа приведены для полного варианта установки и наличии всех ролей и функций ОС.
Насколько же изменится ситуация в варианте установки Server Core?
Говоря языком цифр, получится следующее. Для Server Core со всеми ролями и функциями количество критических обновлений меньше на 35%, суммарное количество всех обновлений на 59%, а перезагрузок при их установке потребуется на 62% меньше, чем для полного варианта установки.
1. Наличие бОльшего количества обновлений и даже критических обновлений для ESX не говорит ни о чем, кроме бОльшего количества обновлений.
2. В обновления ESX включаются так же и обновления драйверов (!). Напомните пожалуйста, как там с обновлением драйверов у Hyper-V?
3. При наличии лицензии VMotion (Live Migration) даунтайма для сервисов при установке обновлений на хост нет вообще. Сравним с Hyper-V, у которого Live Migration только-только выйдет.
4. Обновления VMware выпускаются обычно сразу по несколько и ставятся за один раз, что автоматически опровергает расчеты количества перезагрузок.
Итого, вроде и цифры есть, а толку в них?
Интересна и реакция данного сотрудника Microsoft на вот этот пост у меня в блоге.
Даже не буду комментировать бред параноидального MS-ненавистника.
Статья состоит из списка ложных и ошибочных утверждений. Автор занимается как раз черным маркетингом без зазрения совести. Если есть интерес подискутировать, - велкам, я могу написать ответную заметку (мои комментарии с цифрами там удаляют)...
У меня возник вопрос: параноидальным MS-ненавистником назвали Stu (vinternals.com) или меня? И лично я не припомню никаких комментариев с цифрами, не говоря уже о том, чтобы я что-то удалял (за исключением спама).
Да и MS-ненавистником я не являюсь ни в какой мере, за исключением пожалуй, неприязни к многим методам маркетинга MS. И я рад тому, что в рунете есть возможность дискутировать на эту тему с НЕмаркетинговыми специалистами.
Как работает маркетинг Microsoft?
В связи с очередным обострением священной войны между Hyper-V и ESX силами Scott Drummonds (VMware) и Jeff Woolsey (Microsoft) (1, 2, 3), нашлась интересная ссылка (спасибо Duncan Epping).
Строго говоря, не столько само содержание интересно, сколько его официальное подтверждение, поскольку в неофициальном режиме я многократно слышал об этом от представителей Microsoft.
Upd: В данном случае интересно то, что это прямые слова сотрудника Microsoft, а не пересказ кем-то из третьих лиц. С учетом того, что хоть это мнение и не официальная позиция Microsoft, но встречается (точнее встречалось) у практически любого сотрудника MS как под копирку.
Краткое содержание.
Microsoft утверждает, что необходимость в Live Migration (VMotion) - миф. Абсолютное большинство заказчиков все равно планируют обслуживание и установку обновлений на физические хосты в офф-тайм, нерабочее время. Так что нет никакой разницы между 5-20 секундами даунтайма для Quick Migration и менее одной секунды даунтайма для VMotion. Их просто некому будет замечать.
Датировано 24.04.2008
Сравните с текущей позицией Microsoft и размахиванием Live Migration как сверхдостижением, которое нужно всем. Настолько, что Microsoft не стесняется им размахивать в Beta и RC - ведь у них есть теперь Live Migration!
Есть и еще один "факт", который полюбился маркетингу Microsoft - ведь у VMware для виртуализации на один слой больше! У VMware есть слой виртуализации, гипервизор, в то время как у Microsoft есть просто ОС. И тут действительно, добавить к словам Duncan Epping нечего, "вы запускаете ваши ВМ напрямую на железе?"
Upd: В данном случае интересно то, что это прямые слова сотрудника Microsoft, а не пересказ кем-то из третьих лиц. С учетом того, что хоть это мнение и не официальная позиция Microsoft, но встречается (точнее встречалось) у практически любого сотрудника MS как под копирку.
Краткое содержание.
Microsoft утверждает, что необходимость в Live Migration (VMotion) - миф. Абсолютное большинство заказчиков все равно планируют обслуживание и установку обновлений на физические хосты в офф-тайм, нерабочее время. Так что нет никакой разницы между 5-20 секундами даунтайма для Quick Migration и менее одной секунды даунтайма для VMotion. Их просто некому будет замечать.
Датировано 24.04.2008
Сравните с текущей позицией Microsoft и размахиванием Live Migration как сверхдостижением, которое нужно всем. Настолько, что Microsoft не стесняется им размахивать в Beta и RC - ведь у них есть теперь Live Migration!
Есть и еще один "факт", который полюбился маркетингу Microsoft - ведь у VMware для виртуализации на один слой больше! У VMware есть слой виртуализации, гипервизор, в то время как у Microsoft есть просто ОС. И тут действительно, добавить к словам Duncan Epping нечего, "вы запускаете ваши ВМ напрямую на железе?"
Подписаться на:
Сообщения (Atom)
Сообщения
