Приветствуем Вас, уважаемые коллеги.
Некоторое время назад, предвидя перспективы развития виртуализации, мы перешли от модели “хостинга VMware” к предоставлению облачной серверной инфраструктуры корпоративного уровня в виде полноценного виртуального дата-центра на базе решений компании VMware. Во многом это стало возможным благодаря новой линейке продуктов VMware vCloud (VMware vSphere, VMware vCenter, VMware vCloud Director, VMware vShield), активными бета тестерами которых наша компания являлась ранее.
Данное семейство продуктов позволяет нам предоставить большие возможности в части автономного управления инфраструктурой и ее компонентами самими сотрудниками клиента. Также в дополнение к ранее заявленной модели биллинга за заказанные ресурсы, теперь мы имеем возможность предлагать оплату ресурсов по фактическому потреблению (Pay-as-you-Go), что несомненно будет востребовано нашими потенциальными клиентами, особенно всевозможными интернет проектами.
Для обкатки решения и получения, так сказать, взгляда со стороны, мы обратились к Михаилу Михееву – известному специалисту по продуктам VMware, имеющему звание VCP по трем поколениям продуктов этой компании и звание VMware vExpert, с просьбой независимого экспертного тестирования нашего облака.
В результате чего родился ряд авторских постов, раскрывающих аспекты работы с первым в России публичным облаком компании ИТ-ГРАД реализованным на технологии VMware vCloud, которые мы и представляем вашему вниманию.
Последнее время IT-шник только и слышит: «облака облака облака». А что скрывается за этим? Какая конкретика? Давайте об этом поговорим.
Очевидно, что для разных специалистов и разных сфер бизнеса «облачность» может быть применена по-разному, да и просто могут использоваться разные типы облаков. Вот хотелось бы навести ясность в этом вопросе, проговорив некоторые конкретные моменты.
Итак, для первого разговора определим компанию: обычная. В штате сотня человек, плюс минус 50. Есть ИТ-отдел, сервера. Может быть, админов всего двое, и сервера лишь под минимально необходимые задачи. А может быть инфраструктура уже посущественней – в сетях все хорошо, серверов побольше (и терминальные, и всякое вспомогательное к AD, и ip-телефония и пр. Возможно, уже используется серверная виртуализация).
Определив компанию, определим ситуацию, в которой «cloud computing» был бы интересен.
В первую очередь, это какой-либо новый проект. Хочется перейти на новую версию MS Exchange. Или начать использовать терминальные сервера. Или внедрить ERP. Или…
Решаем вопрос по классической схеме:
Можно возразить, что если виртуализация уже есть, то там все проще – просто добавляем виртуалок и все. Но даже в случае уже развернутой виртуальной инфраструктуры в какой-то момент времени ресурсов хватать перестает, и нужны еще сервера. В каком-то проценте случаев иметь проблемы из-за недостаточных ресурсов – огрехи планирования или урезания бюджета.
Альтернативная схема – разместить новый кусочек инфраструктуры за пределами своей серверной:
Разница между этими вариантами не столько в количестве шагов, сколько во времени их выполнения и сложности. Второй вариант значительно быстрее, проще в организации и часто интереснее по количеству и характеру затрат. При том – от нас потребуется понимание «что нам надо» в виде «нам надо четыре Windows, общающиеся между собой по внутренней сети, и пятая, имеющая выход еще и в публичную сеть нашей компании». Ну, и сколько им примерно требуется ресурсов — такие подробности, как:
Нас не интересуют физическая инфраструктура и ресурсы — «где-то там» их в избытке, и нам с удовольствием предоставят именно столько, сколько нам будет необходимо.
Закладывать на отказоустойчивость часто (да всегда, говоря откровенно) можно будет меньше денег, так как большой облачной инфраструктуре проще обеспечить резервирование на всех уровнях за счет масштаба.
Разумеется, кроме новых возможностей, появляются и новые проблемы – о них смело поговорим чуть позже.
Итак, берем конкретную задачу. Сразу оговорим – задача не из разряда «представим, например, сферического коня в вакууме», а наоборот, конкретная. Может быть, именно такая вам неактуальна – но на ее примере можно показать идею и возможности. Плюс к тому, в дальнейшем будут приведены примеры других задач.
Итак, задача.
Проверить, что из себя представляет модный VDI. Для этого нам хочется поднять небольшую инфраструктуру VMware vSphere + VMware View — сначала в тестовом виде, затем превратить ее в маленький пилотный проект, и если все понравится – начать эксплуатировать более масштабно.
Что получается: шаги 2 и 3 мы, вероятно, захотим разворачивать внутри своей инфраструктуры. А вот шаг 1 разворачивать «внутри» не всегда удобно – банально нужно железо. Поэтому шаг 1 мы делаем примерно вот так (рис.2):
Пользуясь тем, что ESX(i) может быть запущен в ВМ под ESX(i), мы арендуем ресурсы под следующие виртуальные машины для тестовой площадки нашего проекта:
Некоторое время назад, предвидя перспективы развития виртуализации, мы перешли от модели “хостинга VMware” к предоставлению облачной серверной инфраструктуры корпоративного уровня в виде полноценного виртуального дата-центра на базе решений компании VMware. Во многом это стало возможным благодаря новой линейке продуктов VMware vCloud (VMware vSphere, VMware vCenter, VMware vCloud Director, VMware vShield), активными бета тестерами которых наша компания являлась ранее.
Данное семейство продуктов позволяет нам предоставить большие возможности в части автономного управления инфраструктурой и ее компонентами самими сотрудниками клиента. Также в дополнение к ранее заявленной модели биллинга за заказанные ресурсы, теперь мы имеем возможность предлагать оплату ресурсов по фактическому потреблению (Pay-as-you-Go), что несомненно будет востребовано нашими потенциальными клиентами, особенно всевозможными интернет проектами.
Для обкатки решения и получения, так сказать, взгляда со стороны, мы обратились к Михаилу Михееву – известному специалисту по продуктам VMware, имеющему звание VCP по трем поколениям продуктов этой компании и звание VMware vExpert, с просьбой независимого экспертного тестирования нашего облака.
В результате чего родился ряд авторских постов, раскрывающих аспекты работы с первым в России публичным облаком компании ИТ-ГРАД реализованным на технологии VMware vCloud, которые мы и представляем вашему вниманию.
Последнее время IT-шник только и слышит: «облака облака облака». А что скрывается за этим? Какая конкретика? Давайте об этом поговорим.
Очевидно, что для разных специалистов и разных сфер бизнеса «облачность» может быть применена по-разному, да и просто могут использоваться разные типы облаков. Вот хотелось бы навести ясность в этом вопросе, проговорив некоторые конкретные моменты.
Итак, для первого разговора определим компанию: обычная. В штате сотня человек, плюс минус 50. Есть ИТ-отдел, сервера. Может быть, админов всего двое, и сервера лишь под минимально необходимые задачи. А может быть инфраструктура уже посущественней – в сетях все хорошо, серверов побольше (и терминальные, и всякое вспомогательное к AD, и ip-телефония и пр. Возможно, уже используется серверная виртуализация).
Определив компанию, определим ситуацию, в которой «cloud computing» был бы интересен.
В первую очередь, это какой-либо новый проект. Хочется перейти на новую версию MS Exchange. Или начать использовать терминальные сервера. Или внедрить ERP. Или…
Решаем вопрос по классической схеме:
- Обосновать проект.
- Утвердить бюджет.
- Дождаться серверов.
- Начать выполнение проекта.
Можно возразить, что если виртуализация уже есть, то там все проще – просто добавляем виртуалок и все. Но даже в случае уже развернутой виртуальной инфраструктуры в какой-то момент времени ресурсов хватать перестает, и нужны еще сервера. В каком-то проценте случаев иметь проблемы из-за недостаточных ресурсов – огрехи планирования или урезания бюджета.
Альтернативная схема – разместить новый кусочек инфраструктуры за пределами своей серверной:
- Обосновать проект.
- Заключить договор с компанией облако-владельцем (в данном случае компанией ИТ-ГРАД).
- Начать выполнение проекта.
Разница между этими вариантами не столько в количестве шагов, сколько во времени их выполнения и сложности. Второй вариант значительно быстрее, проще в организации и часто интереснее по количеству и характеру затрат. При том – от нас потребуется понимание «что нам надо» в виде «нам надо четыре Windows, общающиеся между собой по внутренней сети, и пятая, имеющая выход еще и в публичную сеть нашей компании». Ну, и сколько им примерно требуется ресурсов — такие подробности, как:
- конфигурация физических серверов, на которых будут работать эти виртуалки;
- схема соединений, физическая коммутация сети;
- страхи «а достаточно / а не лишние ли ресурсов».
Нас не интересуют физическая инфраструктура и ресурсы — «где-то там» их в избытке, и нам с удовольствием предоставят именно столько, сколько нам будет необходимо.
Закладывать на отказоустойчивость часто (да всегда, говоря откровенно) можно будет меньше денег, так как большой облачной инфраструктуре проще обеспечить резервирование на всех уровнях за счет масштаба.
Разумеется, кроме новых возможностей, появляются и новые проблемы – о них смело поговорим чуть позже.
Итак, берем конкретную задачу. Сразу оговорим – задача не из разряда «представим, например, сферического коня в вакууме», а наоборот, конкретная. Может быть, именно такая вам неактуальна – но на ее примере можно показать идею и возможности. Плюс к тому, в дальнейшем будут приведены примеры других задач.
Итак, задача.
Проверить, что из себя представляет модный VDI. Для этого нам хочется поднять небольшую инфраструктуру VMware vSphere + VMware View — сначала в тестовом виде, затем превратить ее в маленький пилотный проект, и если все понравится – начать эксплуатировать более масштабно.
Что получается: шаги 2 и 3 мы, вероятно, захотим разворачивать внутри своей инфраструктуры. А вот шаг 1 разворачивать «внутри» не всегда удобно – банально нужно железо. Поэтому шаг 1 мы делаем примерно вот так (рис.2):
Пользуясь тем, что ESX(i) может быть запущен в ВМ под ESX(i), мы арендуем ресурсы под следующие виртуальные машины для тестовой площадки нашего проекта:
- 1 или 2 виртуальные машины под ESX(i), 1 vCPU, 4 Гб ОЗУ
- 1 ВМ под vCenter, 1 vCPU, 2 Гб ОЗУ
- 1 ВМ под View Server, 1 vCPU, 1 Гб ОЗУ.>> продолжение...
