как на euronews - no comment
VMware toolbar
У VMware есть toolbar для разных там браузеров. Хранится он тут. Выглядит так:
Насколько он полезен, удобен и юзабилен - вопрос очень личный =)
Агрегатор канала VMware на youtube с проверкой обновлений, удобный поиск по базе знаний и документации, твитер, новости, facebook.
Насколько он полезен, удобен и юзабилен - вопрос очень личный =)
Агрегатор канала VMware на youtube с проверкой обновлений, удобный поиск по базе знаний и документации, твитер, новости, facebook.
VMUG Belarus
В начале октября в городе Минске будет проведена первая в РБ встреча VMware User Group. Точная дата и программа будут опубликованы в ближайшее время.
Список докладчиков еще открыт. Так что, если у Вас есть желание + о чем рассказать, будем рады предоставить такую возможность.
VMUG - хорошая возможность поделиться опытом, пообщаться в неформальной обстановке с коллегами, представителями VMware и других профильных компаний.
На VMUG говорят о технологиях, никакого маркетинга, продаж и т.п.
Список докладчиков еще открыт. Так что, если у Вас есть желание + о чем рассказать, будем рады предоставить такую возможность.
VMUG - хорошая возможность поделиться опытом, пообщаться в неформальной обстановке с коллегами, представителями VMware и других профильных компаний.
На VMUG говорят о технологиях, никакого маркетинга, продаж и т.п.
Basic Troubleshooting
У VMware есть неплохая схема по траблшутингу. При возникновении проблем с производительностью VMware рекомендует проверить ряд параметров. Параметры сгруппированы по величине их вклада в производительность, точнее в ухудшение этой самой производительности.
симбиоз Citrix XenApp и VMware vSphere
Про PCI DSS пока перерыв, а пока о том, как я "дружил" Citrix XenApp и VMware vSphere, зачем мне это было надо и что из этого получилось.
Citrix XenApp - решение для доставки приложений Windows, позволяющее осуществлять виртуализацию, централизацию, управление из центра обработки данных и доставку приложений по запросу на любое пользовательское устройство вне зависимости от его местоположения.
Реализуется это все достаточно просто: создается ферма терминальных серверов, на которых "публикуются" приложения для пользователей. На устройствах пользователей устанавливается клиентская часть, которая предоставляет пользователю доступ к приложениям на серверах фермы. Для обеспечения отказоустойчивости и балансировки нагрузки одинаковые каждое приложение публикуется на нескольких серверах. Приложения выполняются на серверах, пользователь получает картинку.
Фермы терминальных серверов Citrix XenApp отлично масштабируется добавлением дополнительных мощностей (серверов) и размазыванием пула пользователей по большему количеству ресурсов, что, естественно, приводит к уменьшению нагрузки на каждый сервер.
В процессе администрирования я столкнулся с рядом "неудобств":
- сервера, ОС имеют свойство ломаться. Как показывает мой опыт администрирования Citrix сервера с XenApp ломаются чаще, чем без него. Конечно, если в вашей ферму полсотни серверов и приложения разнесены по всем бестпрактисам обеспечения отказоустойчивости и производительности - потеря одного сервера не становится глобальной проблемой. Но вот повторное добавление сервера в ферму после ремонта процедура совершенно неинтересная и малопривлекательная, а чтобы восстановиться до исходного состояния все должно быть хорошо задокументировано. Бэкапить физические сервера процедура неудобная, а с учетом динамики изменения настроек серверов Citrix XenApp для поддержания актуального бэкапа - эти неудобства придется терпеть очень часто.
- различные требования публикуемых приложений к CPU и RAM. Казалось бы это не проблема: публикуй на каждом сервере приложение требовательное к CPU и приложение требовательное к RAM и будут задействованы все ресурсы. Все это хорошо "сайзится" на десятке приложений. Когда приложений ставятся сотни + территориальная разнесенность офисов (генерирование специфических нагрузок в разное время суток) + востребованность некоторых приложений в определенные дни месяца - и вот задача эффективного использования доступных ресурсов становится совсем не тривиальной.
- требования безопасников к изоляции приложений на серверах. Зачастую приходится выделять целый сервер под одно приложение + еще один для отказоустойчивости. А приложением может использовать всего пара пользователей...
-требования IT подразделений занимающихся тестированием и отладкой приложений. Обычно, эти ребята тоже хотят под каждое тестируемое приложение отдельный сервер. Это позволяет избежать "воздействия сторонних факторов создаваемых инородными приложениями". А с учетом того, что тестирование это процесс идущий по графику час тестирую, день не тестирую, то неэффективное использование ресурсов увеличивается.
Решить эти неудобства я попытался с помощью приживления Citrix XenApp в инфраструктуру VMware vSphere:
с реализацией все понятно из схемы, а вот про плюсы и минусы стоит поговорить.
Минусы:
- это дорого, точнее дороже чем первый вариант. Citrix XenApp лицензируется конкурентными пользовательскими лицензиями, а вот на лицензии ОС и vSphere придется потратиться. Простая истина о том, что нельзя получить отказоустойчиво, удобно, быстро и "задешева" работает.
- накладные расходы: как может показаться с первого взгляда расход гигагерцев и гигабайтов физических серверов на нужды ESXi и большее количество ОС Windows будем достаточно большим. Но при реализации осознанного подхода к разнесению приложений по серверам потери будут соизмеримы с потерями при "сайзинге" первой схемы.
Плюсы:
-восстановление после аварии. тут все очевидно: о удобстве резервного копирования и восстановления виртуальных машин написано уже достаточно, повторятся нет смысла. Делая бэкапы виртуальных машин с Citrix XenApp каждую ночь мы получаем при востановлении полностью эквивалентные по настройкам сервера, а если посмотреть на бэкап сотни виртуальных серверов с Citrix XenApp сквозь призму дедупликации, то на выходе мы получаем еще и небольшой по размеру бэкап большой инфраструктуры.
- проблема "сайзинга" решена. Выделяйте виртуальным машинам ресурсы согласно потребностям опубликованных на них приложений. Падкое на быстрые гигагерцы приложение публикуйте на виртуальных серверах которым выданы эти гигагерцы, на толстые гигабайты - на серверах с толстыми гигабайтами. А нехватку ресурсов всегда можно мониторить и компенсировать.
- желания и требования любителей схемы одно приложение = один сервер тоже решена.
- траблшутинг ошибок Citrix XenApp исчез как вид. Большинство проблем устраняется восстановлением всей виртуальной машины.
Citrix XenApp - решение для доставки приложений Windows, позволяющее осуществлять виртуализацию, централизацию, управление из центра обработки данных и доставку приложений по запросу на любое пользовательское устройство вне зависимости от его местоположения.
Реализуется это все достаточно просто: создается ферма терминальных серверов, на которых "публикуются" приложения для пользователей. На устройствах пользователей устанавливается клиентская часть, которая предоставляет пользователю доступ к приложениям на серверах фермы. Для обеспечения отказоустойчивости и балансировки нагрузки одинаковые каждое приложение публикуется на нескольких серверах. Приложения выполняются на серверах, пользователь получает картинку.
Фермы терминальных серверов Citrix XenApp отлично масштабируется добавлением дополнительных мощностей (серверов) и размазыванием пула пользователей по большему количеству ресурсов, что, естественно, приводит к уменьшению нагрузки на каждый сервер.
В процессе администрирования я столкнулся с рядом "неудобств":
- сервера, ОС имеют свойство ломаться. Как показывает мой опыт администрирования Citrix сервера с XenApp ломаются чаще, чем без него. Конечно, если в вашей ферму полсотни серверов и приложения разнесены по всем бестпрактисам обеспечения отказоустойчивости и производительности - потеря одного сервера не становится глобальной проблемой. Но вот повторное добавление сервера в ферму после ремонта процедура совершенно неинтересная и малопривлекательная, а чтобы восстановиться до исходного состояния все должно быть хорошо задокументировано. Бэкапить физические сервера процедура неудобная, а с учетом динамики изменения настроек серверов Citrix XenApp для поддержания актуального бэкапа - эти неудобства придется терпеть очень часто.
- различные требования публикуемых приложений к CPU и RAM. Казалось бы это не проблема: публикуй на каждом сервере приложение требовательное к CPU и приложение требовательное к RAM и будут задействованы все ресурсы. Все это хорошо "сайзится" на десятке приложений. Когда приложений ставятся сотни + территориальная разнесенность офисов (генерирование специфических нагрузок в разное время суток) + востребованность некоторых приложений в определенные дни месяца - и вот задача эффективного использования доступных ресурсов становится совсем не тривиальной.
- требования безопасников к изоляции приложений на серверах. Зачастую приходится выделять целый сервер под одно приложение + еще один для отказоустойчивости. А приложением может использовать всего пара пользователей...
-требования IT подразделений занимающихся тестированием и отладкой приложений. Обычно, эти ребята тоже хотят под каждое тестируемое приложение отдельный сервер. Это позволяет избежать "воздействия сторонних факторов создаваемых инородными приложениями". А с учетом того, что тестирование это процесс идущий по графику час тестирую, день не тестирую, то неэффективное использование ресурсов увеличивается.
Решить эти неудобства я попытался с помощью приживления Citrix XenApp в инфраструктуру VMware vSphere:
с реализацией все понятно из схемы, а вот про плюсы и минусы стоит поговорить.
Минусы:
- это дорого, точнее дороже чем первый вариант. Citrix XenApp лицензируется конкурентными пользовательскими лицензиями, а вот на лицензии ОС и vSphere придется потратиться. Простая истина о том, что нельзя получить отказоустойчиво, удобно, быстро и "задешева" работает.
- накладные расходы: как может показаться с первого взгляда расход гигагерцев и гигабайтов физических серверов на нужды ESXi и большее количество ОС Windows будем достаточно большим. Но при реализации осознанного подхода к разнесению приложений по серверам потери будут соизмеримы с потерями при "сайзинге" первой схемы.
Плюсы:
-восстановление после аварии. тут все очевидно: о удобстве резервного копирования и восстановления виртуальных машин написано уже достаточно, повторятся нет смысла. Делая бэкапы виртуальных машин с Citrix XenApp каждую ночь мы получаем при востановлении полностью эквивалентные по настройкам сервера, а если посмотреть на бэкап сотни виртуальных серверов с Citrix XenApp сквозь призму дедупликации, то на выходе мы получаем еще и небольшой по размеру бэкап большой инфраструктуры.
- проблема "сайзинга" решена. Выделяйте виртуальным машинам ресурсы согласно потребностям опубликованных на них приложений. Падкое на быстрые гигагерцы приложение публикуйте на виртуальных серверах которым выданы эти гигагерцы, на толстые гигабайты - на серверах с толстыми гигабайтами. А нехватку ресурсов всегда можно мониторить и компенсировать.
- желания и требования любителей схемы одно приложение = один сервер тоже решена.
- траблшутинг ошибок Citrix XenApp исчез как вид. Большинство проблем устраняется восстановлением всей виртуальной машины.
Подписаться на:
Сообщения (Atom)