Про частные «облака»: что и как обычно делается в России, ликбез и основные проблемы

    Моя работа — проектирование решений в области виртуализации и внедрение частных «облаков» для российских компаний. Начну с того, что вообще такое частное «облако»:
    • Это IT-сервисы на вашей территории.
    • При этом это сервисы, эволюционно добравшиеся до «облака», то есть сервисы распределенных вычислений.

    Зачем это нужно? Причин на практике четыре:
    1. Экономия на железе: «облако» позволяет крутить сотни проектов на одном наборе железа, когда как без такой инфраструктуры железа потребовалось бы минимум втрое больше. Ну и в будущем нет проблем с заменой железа.
    2. Экономия на лицензиях: так получилось, что лицензионные условия часто обозначаются не на пользователя, а на машину. А когда машина физически одна, а пользователей — 5-6, это серьезно дешевле.
    3. Требования к скорости развертывания инфраструктуры. Из правильного настроенного частного «облака» можно легко запустить новый офис в регионе, чуть ли не за несколько минут. Или масштабироваться без боли.
    4. Волшебный 152-ФЗ и ряд других нормативов: пока не всегда можно отдавать свои ПД на обработку кому-то третьему, требуется разворачивать фермы у себя.

    Теперь давайте посмотрим, как это обычно делается и какие бывают грабли. Да, и ниже есть ещё бесплатное приглашение на семинар про практику их построения.

    Кто заказывает частные «облака»?


    Как правило — это крупные компании, которые уже достаточно зрелы по процессам. У них уже внедрен сервисный подход, но нужно все это автоматизировать частным «облаком». Сервисный подход — это когда каждая часть IT-сферы рассматривается как услуга для пользователя. Например, нужна виртуальная машина — просто отдали еще один экземпляр с нужными правами и настройками. Централизованно и унифицированно. И так далее.

    Самый первый заказчик — IT-отделы


    Как правило, IT-отделы — это первые, кто понимает, что нужно свое «облако». Обычно происходит так: они поднимают виртуальные машины по запросу для себя, коллег, подрядчиков (кстати, дать доступ подрядчику до своей инфраструктуры — одна из самых частых задач). В какой-то момент становится понятно, что нужно делать платформу — PaaS — и потом все это приходит к SaaS, когда нужная операция делается чуть ли не самим пользователем в один клик. Параллельно описываются все эти процессы и прикидывается их стоимость. Зачем? Потому что зная экономию, куда легче доказывать руководству необходимость такого решения. Появляются понятные для бизнеса деньги. Например, почтовый ящик стоит столько-то, в следующем году будет столько-то новых пользователей и так далее. Появляется главный фактор — цена. И, поверьте, многих несказанно радует переход на язык денег вместо языка «шаманов» обычного IT-департамента.

    Большая головная боль — это тестовые среды


    Один из основных сервисов для крупных компаний — автоматизация предоставления сред под разную разработку. Тестовые среды требуются почти под каждый крупный проект, потому что, например, в нефтегазовой, банковской или телекомовской среде нельзя оттестировать что-то новое на «сухих» данных. Нужно прогонять, например, по вчерашнему слепку базы в контролируемой среде и смотреть, что на выходе. Когда такой проект один, просто выделяется некий парк серверов, и все гоняется на нем.

    Но когда проектов уже десяток — нужны виртуальные тестовые среды. Причем нужны позарез. Их надо развертывать, конфигурировать, убивать или морозить, чтобы они не ели ресурсы. Проектов много, на это уходит ручного труда очень много. Встает вопрос безопасности.

    Инфраструктура компаний


    Когда компания готова перейти на полностью сервисный подход к IT (а так делает большая часть компаний на Западе просто из-за экономической целесообразности), в частном «облаке» настраивается все необходимое обычным пользователям. Как правило, это почта, бекап, место на диске для хранения данных, виртуальные машины.

    Отдельный вопрос — мощность для масштабирования. Например, для колл-центра с ярко выраженными сезонными пиками (туристического или, например, имеющего пик под Новый Год) логично не закупать массу железа и лицензий ради двух недель работы в году — они используют виртуальные ресурсы, которые очень легко масштабируются.

    Пиковые задачи


    В Big Data (вроде биллинга телекомов, расчета тарифов страховых и так далее) есть задачи, которые возникают раз в месяц и полностью убивают даже тяжелые сервера-молотилки. Например, один из известных мне расчетов шел на физическом оборудовании месяцы, после первого цикла виртуализации — недели, а теперь все свободные ресурсы их «облака» занимаются именно этим подсчетом (и при этом не тормозят остальные процессы) — и все проходит за дни.

    Потом идут новые проекты


    Предположим, банк запускает какой-то проект, про который совершенно непонятно, сколько он будет брать ресурсов. Непонятно потому, что стартап внутри компании новый, и никто не может сказать — будет это 500 человек, 1% от клиентской базы или вообще каждый второй клиент. Соответственно, логично не закупать сначала дорогое железо с одной стороны, но и страховаться от ожидаемого или неожиданного пика — ведь придется задорого менять инфраструктуру, если что. Поэтому здесь тоже логично все крутить в «облаке». Но не в публичном, так как речь о банке и 152-ФЗ.

    SaaS для клиентов


    Иногда случается, что компания не хочет разворачивать «облако» для миграции со своей архитектуры, но не против отдавать сервисы из него своим подрядчикам или клиентам. В этом случае запускается отдельное от общей инфраструктуры частное «облако», откуда, например, могут раздаваться рабочие места и доступы к важным данным в огромных рекламных агентствах или же откуда могут настраиваться защищенные доступы к банк-клиенту, бухгалтерии и эквайрингу для клиентов банков.

    Необычный случай


    В одной крупной энергетической компании ситуация была в целом стандартная — сотни дочерних обществ, множество филиалов, очень сложная структура отдельных компаний внутри объединения. Все это обслуживает одна IT-служба. Парни справляются, все настроено по уму, но есть одна проблема. Конкретно — за IT-услуги (например, виртуальные машины или место на серверах) нужно делать расчеты внутри объединения, а для этого нужно как-то выставлять счета. А делать это нереально сложно, потому что, никто не может чётко проверить, сколько ресурсов потрачено на тот или иной запрос. И предсказать тоже. В итоге они развернули и настроили частное «облако», которое позволило просто и прозрачно перейти к подсчетам ресурсов для каждого. Учитывая, что теперь каждый может взять и посмотреть в реальном времени сколько и за что он должен, споры пропали. Биллинг справедливый. Получился такой хороший финансовый арбитр, позволяющий привести все в норму. Ну и плюс они потом стали постепенно прикручивать другие функции к уже готовому «облаку».

    У нас внутри компании одной из единиц расчета является процессорное время — например, каждый проект имеет квоту на использование ресурсов «облака», и не переходит ее. Квота определяется по приоритету проекта. Для нас это очень удобно, потому что еще завязано на систему менеджмента, где прямо при решении о важности проекта подцепляется все необходимое.

    Вот как такое распределение может выглядеть из интерфейса управления:



    А вот пример внутренних расчетов:



    Как обычно внедряется частное «облако»?


    На практике — с трудом. Основная проблема, с которой я сталкивался — это простое непонимание того, как все работает и чем может быть выгодно. Бывает, мне пишут из IT-отделов, просят сделать расчет, чтобы они его могли показать руководству. Берут свои расчеты, берут мои расчеты — и только две этих бумажки вместе (чтобы было и мнение сотрудника, и внешней компании) убеждают. Когда решение все же принято, шаги внедрения такие:

    1. Сначала IT-службы обсуждают, что и как должно быть.
    Формируется каталог сервисов, потом смотрим, какие куски уже реализованы, а какие нет. Например, выделение виртуальной машины по запросу — сервис не для конечного пользователя, а для разработчика или для подрядчика. Соответственно, он автоматизируется, детализируется, пишется SLA. Или расширение фермы на 100 пользователей — нужно делать связь с другой частью фермы. И так далее.

    2. Каждый сервис детализируется.

    3. Затем смотрим, что уже есть и можно использовать в развертывании «облака».
    Например, есть сервисдеск-система. Все это прописывается в реалиях частного «облака».

    4. Затем стандартные вещи.
    Это выбор вендора, подсчет стоимости, точный финансовый план до копейки по железу, работам, лицензии на продукты для создания «облака», интеграции.

    5. Ну и потом, непосредственно, работы.

    Пример реализации


    Расскажу про наш собственный опыт. Нам, как проектной компании, которая занимается разработкой новых решений или донастройкой коробочных решений, необходима среда разработки и среда для тестирования. До 2006-2007 года вся наша лаборатория состояла из железных серверов, то есть фактически под каждый из проектов нужно было сформировать спецификацию, где-то заказать или найти на складе сервера, привезти их, смонтировать, подключить. Если мощности не хватало, то это опять заказ, ожидание и привоз. Почти каменный век.

    Потом появились платформы виртуализации VMware (здесь важно пометить, что альтернативы ей на тот момент де факто не было). Мы решили закупить несколько мощных серверов, поставить на них VMware Server, и облегчить всем жизнь. После этого действительно стало полегче с точки зрения скорости развертывания, но не сильно. Потому что все это развертывалось фактически вручную, даже несмотря на наличие механизмов по управлению этими виртуальными серверами, все равно наши админы большую часть работы делали сами: принимали заявки, выделяли вычислительные мощности, вручную отслеживали насколько тот или иной сервер сейчас загружен. Зачастую возникали ситуации, что конкретный железный сервер настолько был загружен виртуалками, что приходилось его вручную оптимизировать, переносить виртуалки с сервера на сервер. Все это жутко мешало работе проектных команд. Они заказывали определенную мощность, но получить ее не могли.

    Вывод: виртуализация хороша, но ручное управление – плохо. По решению инженера, которое принималось по принципу «пол-палец-потолок», тот или иной сервер был менее загружен, чем другой. Только потому, что на нем сейчас не запущены те виртуалки, которые на нем стоят. А предугадать, что сейчас этот проект войдет в горячую фазу и все эти виртуалки стартуют, было практически невозможно. Нужен был очень умный инженер, который мог бы уточнять планы по проектам. А когда их сотни одновременно, это та еще задача. Многие перестали заказывать виртуалки, потому что работать так было очень сложно, и заказывали реальное железо, всеми правдами и неправдами. Но понятно, что повесить железный сервер на проект – это существенно дороже. В разы, если не на порядки.

    Поэтому конечно, когда появилась возможность поставить платформу управления, мы ее поставили. Выбрали HP, отчасти потому, что у нас был большой опыт работы с их системами, отчасти, потому что из реальных конкурентов HP в плане управления «облаком» на тот момент был только BMC. Но под наши разработческие задачи, чтобы пользователи могли сами выбирать себе параметры стенда, больше подходил HP с точки зрения гибкости управления. Когда мы все это дело автоматизировали, то уже не нужно думать, где крутится виртуалка, она сама переносится с одной вычислительной мощности на другую, для того чтобы поддерживать необходимый уровень производительности. Если какой-то определенный необходимый квант мощности превышен, то она сама добавляет еще и еще. Теперь наши инженеры практически не заказывают железные сервера.

    Потом уже мы доработали эту систему управления коннектором к публичному «облаку» (в Amazon и к нашему собственному публичному «облаку» — прикрутили и возможность выбора), чтобы можно было показать заказчику получившееся решение в любом месте, где есть интернет. У CA, например, по умолчанию есть прямой коннектор к публичным «облакам». Поэтому если кто-то не хочет заморачиваться на доработку, в некоторых случаях можно выбрать CA.

    Сейчас в нашем частном «облаке» порядка 1000 стендов, понятно, что они не все активированы, но в среднем каждый пятый работает постоянно. Сервера самые разные, с точки зрения «облака» на самом деле не очень важно какие, могут быть IBM Blade или HP Blade. Подключившись к «матрице» он просто становится еще одной каплей в море. Затраты конкретного стенда сейчас автоматически, благодаря внутренней системе биллинга, падают на конкретный проект. С точностью до копейки. Не больше, не меньше. Причем с учетом простоя, то есть если ты останавливаешь виртуалку на какое-то время, то и не платишь. Конечно, небо и земля, по сравнению с тем, как это было раньше, когда все затраты лаборатории каким-то магическим и совершенно непрозрачным образом распределялись по департаментам, направлениям, группам.

    Но пойдём дальше.

    Масштабирование


    Обычно делается очень просто. Есть предопределенные блоки: автоматизация охватывет инфраструктурный уровень. Все, по большей части, решается установкой дополнительных юнитов в стойки в случае чего. Если задача не очень большая — то скорее всего допоставка серверов, систем хранения, связка воедино. Если крупная — развертывание еще фермы и организация связи между ними. Соответственно, легко строить прогнозы вроде «в следующем году у нас будет на 30% больше пользователей, вот расходы».

    Архитектура


    На высоком уровне она общая, одинаковая для ряда производителей. Дальше выбираются конкретные решения как из коммерческих так и из опенсорсных реализаций, идет диалог о деталях, железе и так далее. Определяем, какие функции исполняет какой компонент какого производителя.

    Вот про управление:

    image
    ПРИМЕР АРХИТЕКТУРЫ НА ПЛАТФОРМЕ BMC CLOUD LIFECYCLE MANAGEMENT


    ПРИМЕР АРХИТЕКТУРЫ НА ПЛАТФОРМЕ IBM CLOUD SERVICE PROVIDER PLATFORM (CSP2)


    ПРИМЕР АРХИТЕКТУРЫ НА ПЛАТФОРМЕ CA AUTOMATION SUITE FOR CLOUD


    Схема с общими составляющими инфраструктуры частного «облака»

    Переход к гибридам и публичным «облакам»


    В своем частном «облаке» заказчики часто оттачивают механизм оказания сервисов. Затем, когда они понимают чувствительность данных, они уже спокойно могут использовать облака партнеров, гибриды или публичные. Например, банки отрабатывают важные данные в своей собственной безопасной среде — у них появляются навыки, новые процедуры безопасности, автоматизация и так далее. Когда становится понятно, что нужны новые ресурсы, и в целом их использование не является угрозой ИБ, используются ресурсы публичных облаков — это просто дешевле, чем разворачивать еще ферму внутри себя.

    Вопросы


    Все. Я готов ответить на ваши вопросы в комментариях или в почте IShumovskiy@croc.ru. Если это требуется, могу прислать примерные расчеты вариантов внедрений для вашей ситуации.

    Если хотите больше практических деталей — завтра с 10:30 до 15:30 у нас в офисе пройдет семинар. Будем рассказывать в подробностях про архитектуру «облака» и «облачный» ITSM, про опыт переноса в частное «облако» услуги «service desk», про пред-биллинг и решения для учета ресурсов, о том, как управлять частными «облаками», какие решения для этого есть и что лучше выбрать в том или ином случае, в целом про аппаратные и системные решения, необходимые для развертывания частного «облака», про защиту «облачных» данных и еще много всяких полезностей. Будет и специальный гость из Forrester — Лорен И. Нельсон, аналитик по работе со специалистами в области ИТ-инфраструктуры и операций. Тоже обещает поделиться некоторыми секретами. В общем, приходите, это полезная ачивка. Зарегистрироваться на бесплатное участие можно здесь.
    КРОК
    434,79
    IT-компания
    Поделиться публикацией

    Комментарии 31

      +1
      Вы описали крутую штуку! Спасибо!
      Биллинг ресурсов виртуалок самописный, правильно понимаю? Вы его не продаёте, случаем?
      Можете вкратце описать как платформа управления HP цепляется к гипервизорам сторонних производителей (я так понимаю vmware)?
        +1
        Биллинг ресурсов виртуальной платформы VMWare разработан HP и является коробочным решением.

        Если мы говорим о сборе информации по использованию виртуальных ресурсов, в частности для платформы VMWare, то возможно два варианта:
        1. Разработка собственных скриптов, которые вытягивают информацию уже собранную VMWare Chargeback Manger (через API VMWare).
        2. Использование коробочного продукта HP Performance Virtualization Viewer который посредством подключения к vCenter сам собирает информацию по использованию виртуальных ресурсов.
        +1
        Решение задач автоматизации распределения ресурсов, их учёта и прогнозирования, это важно, и полезно. И тут приводятся частично вполне уместные аргументы. Но зачем пытаться выдумать какие-то странные причины, чтобы продать клиентам то, что им и без них нужно?

        Экономия на железе: «облако» позволяет крутить сотни проектов на одном наборе железа, когда как без такой инфраструктуры железа потребовалось бы минимум втрое больше. Ну и в будущем нет проблем с заменой железа

        Это позволяет отнюдь не только облако. Даже виртуализация для этого не обязательна. Особенно, если требования проектов не меняются каждую минуту. А они, обычно, всё же довольно предсказуемы.
        Но это ладно, Действительно управлять единым целым проще, чем набором серверов/виртуалок отдельных проектов, но какого перепугу, у вас в облаке волшебным образом вдруг утроятся ресурсы? Чёрт, это явный маркетологический бред, почему не 10? Не 100? Нет, естественно, определённые часть мощностей можно будет перераспределить, но чтобы разница была аж в 3 раза, это как безграмотно всё должно быть распределено до того? Как то не похоже на типичный случай.

        Отдельный вопрос — мощность для масштабирования. Например, для колл-центра с ярко выраженными сезонными пиками (туристического или, например, имеющего пик под Новый Год) логично не закупать массу железа и лицензий ради двух недель работы в году — они используют виртуальные ресурсы, которые очень легко масштабируются.

        И опять передёргивание. Ресурсы виртуальные из неоткуда не возьмутся, т.е. необходимое для обслуживания пика запросов железо, всё же должно быть в наличии. Или придётся подвинуть другие сервисы/отделы/проекты. А это возможно далеко не всегда. Так что откуда тут взяться экономии?

        Волшебный 152-ФЗ и ряд других нормативов: пока не всегда можно отдавать свои ПД на обработку кому-то третьему, требуется разворачивать фермы у себя.
        Ну а это-то как вообще к облакам относится? Наоборот бы, изолировать логично.


        Затраты конкретного стенда сейчас автоматически, благодаря внутренней системе биллинга, падают на конкретный проект. С точностью до копейки. Не больше, не меньше. Причем с учетом простоя, то есть если ты останавливаешь виртуалку на какое-то время, то и не платишь.

        И что — высвобождаются временно мощности. И она, на самом деле, не бесплатны. И далеко не всегда найдётся применение им в другом месте.
        Поэтому точность этой оценки очень идеализирована, как мне кажется.
          0
          В топике дан конкретный сценарий, в котором «частное облако» хорошо работает. Так что ваши контр-примеры (вполне разумные, для сферического коня в вакууме) здесь не подходят.

          Обратите внимание, речь идет о внутренней лаборатории в компании интеграторе. Ребята поступили очень грамотно, и в итоге первоначальные инвестиции окупают именно те подразделения, которым лаборатория нужна. Это полезно и для самих подразделений (стенды не застаиваются, ресурсы экономятся), и для руководства (прозрачность затрат, можно посчитать сроки окупаемости, понять ставку маржинальности).

          Есть и другие подобные сценарии, уже внутри обычных коммерсантов. Как правило это компании, в которых департамент ИТ выделен в отдельное «хозрасчетное» подразделение.
            0
            Обратите внимание — пункты перечисленные в начале, и которые мы обсуждаем, относились не к конкретному кейсу, а к причинам, зачем потенциальному клиенту нужно облако, а ни чем оно хорошо в каком-то конкретном кейсе. И в этом разрезе совершенно не выдерживают критики.
              0
              Шапка не совсем корректна, согласен. Да и по тексту достаточно эмоциональных высказываний и недоговариваний (как про ресурсы колл-центра). Но все же топик про конкретный пример, отсюда и все нестыковки.
                0
                Волшебный 152-ФЗ и ряд других нормативов: пока не всегда можно отдавать свои ПД на обработку кому-то третьему, требуется разворачивать фермы у себя.

                Ну а это-то как вообще к облакам относится? Наоборот бы, изолировать логично.

                если я верно понял, то как раз развёрывание облака в компании, в случае если данный закон затрагивается. Иначе облако можно и в удаленном датацентре развернуть.
                Так что, тут идёт изолирование в локальном облаке.
              0
              Основные моменты которые вы не учитываете в своих рассуждениях – это технология оркестровки и бюджеты использования ресурсов.

              1. Оркестровка — это автоматизация сквозных комплексных процессов управления виртуальной средой. Данное решение позволяет высвобождать ресурсы остановленных виртуальных машин и возвращать их в пул свободных ресурсов за считанные минуты. Это существенно повышает утилизацию виртуальных ресурсов. Нужно так же учитывать, что высвобожденные ресурсы — прежде всего CPU и оперативная память, использование которых универсально для любых “других мест”. Важным аспектом также является высвобождение лицензий, например для ОС Microsoft в разрезе автоматического освобождения и регистрации в центре лицензий Microsoft. Увеличение ресурсов в ~ 3 раза доcтигаеться как раз за счет автоматизации. Безграмотность организации тут совсем не причем. И, естественно, это экспертная оценка для конкретного кейса, а не сферической абстракции.

              2. Распределение стоимости потребления ресурсов на проекты выполняется на основе потребления. Причем с детализацией до часа, что мотивирует ответственных менеджеров следить за освобождением неиспользуемых ресурсов, так как бюджеты для проектов имеют ограничения. Если бы не было детального учета потребления и счета выставлялись бы на месячной основе, то, естественно, менеджеры не занимались более детальным контролем потребления. Переход на почасовую оценку или на оценку по объему потребления имеет смысл именно при наличии платформы управления облаком, которая автоматизирует процессы предбиллинга, сбора использования ресурсов и высвобождения ресурсов. В противном случае такой подход не будет работать.

              3. Про изоляцию — так частное облако и является изолированной средой. Другое дело, если мы говорим о гетерогенном облаке, когда могут использоваться ресурсы как частного облака, так и публичного (например Амазона).
                0
                1. Почему же, как раз учитываю, и писал об этом, но чтобы разница была в три раза, надо, чтобы в среднем 3/4 ресурсов простаивало в одном месте, и в то же время была необходима в других местах, и это должно быть устойчивой ситуацией. Очень странный кейс. Либо вы некорректно оцениваете эту разницу всё же, либо Организация распределения ресурсов до облака была всё же отвратительной.
                А с экономией лицензий я и не спорил — если возможно их освобождать, и они не оплачиваются какое-то время, то это конечно выгодно.
                Мне тут вообще не о чем спорить, т.к. я не в курсе, как производится лицензирование продуктов Microsoft. =)

                2. С точки зрения повышения ответственности в расходовании ресурсов да полезно, согласен.

                3. Это не изоляция. В данном случае — увеличивается количество пресонала, который теоретически может получить доступ к этим данным, даже если не рассматривать техническую сторону вопроса. Изоляция будет если всё это будет варится в рамках отдельного отдела и отдельных серверов.
                  0
                  1. Почему же, как раз учитываю, и писал об этом, но чтобы разница была в три раза, надо, чтобы в среднем 3/4 ресурсов простаивало в одном месте, и в то же время была необходима в других местах, и это должно быть устойчивой ситуацией. Очень странный кейс. Либо вы некорректно оцениваете эту разницу всё же, либо Организация распределения ресурсов до облака была всё же отвратительной.

                  Скорее всего " Организация распределения ресурсов до облака была всё же отвратительной". Но, ИМХО, это может зависеть не только от кривости рук администраторов, но и от множества «политических» составляющих. Использование же облака позволяет нивелировать многие вопросы.

                  теоретически может получить доступ к этим данным

                  Теоретически можно получить доступ хоть к серверам Пентагона, но это же теоретически.
              0
              1) Частное облако для экономии ресурсов — фейк. Даже наоборот, все эти потуги с виртуализацией увеличивают требования к железу, по сравнению с обычным размещением. Другое дело, что управление всем зоопарком при виртуализации гораздо удобнее, но об этом как раз и не написано.

              2) Лицензирование почти у всех вендоров сейчас учитывает виртуализацию. А вообще может оказаться даже дороже из-за overcommit ядер, как например для MS SQL Server.

              3) «масштабирование без боли» требует большого резерва мощностей, которые стоят денег и греют воздух. Это особенно касается тестовых сред.

              Реальная польза виртуализации получается когда приложения знают об этой самой виртуализацией и могут автоматически подстривать потребление ресурссов под профиль использования.

              На примере с порталом — в рабочее время поднимать больше виртуалок с веб-серверами для облуживания запросов, а в нерабочее время поднимать backend серверы для обхода и построения поискового индекса.
              Увы готовых таких решений для private cloud я пока еще не видел.
                +1
                1) Частное облако/виртуализация экономит не ресурсы, а деньги. Уже закупленные ресурсы никак не сэкономишь (если только в аренду сдавать), а вот эффективно их использовать и закупать — можно. Про требования к железу посмотрите ссылочку. Виртуализация, конечно, увеличивает требования к железу, но на такие копейки, что даже не интересно разговаривать.

                2) Это «учитывание» — палка о двух концах. Причем хороших концов существенно больше.

                3) «масштабирование» это не просто наращивание инстансов (как в примере с веб-серверами), а гораздо более широкое понятие. Как правило, это означает возможность увеличивать мощности (ресурсы) инфраструктуры при сохранении ее однородности.
                  –2
                  1) Если ресурсов нет, то надо закупать. Если ресурсы есть, то можно и без виртуализации поднимать приложения на серверах. Где экономия?

                  3) Покупайте одинаковые серваки и будет вам однородность. Тем более, из пункта 1 мы понимаем что серваки уже закуплены. Какую проблему тут решает виртуализация?
                    0
                    1) Экономия в эффективности использования оборудования и в прозрачности затрат. Без виртуализации поднимая множество приложений на одном физическом сервере в рамках одной ОС вы очень быстро столкнетесь с проблемами совместимости, влиянием приложений друг на друга (без возможности развести их по потреблению ресурсов), отказ сразу множества приложений при глюке одного из них и т.д. и т.п. Виртуализация решает эти проблемы за счет изоляции приложений на уровне ОС, плюс к этому уменьшает время простоя за счет защиты HA на уровне кластера.

                    3) Вы как то очень примитивно все понимаете. Однородность — это не одинаковые серваки (кстати, в случае виртуализации, одинаковые серваки в принципе не обязательны). Однородность, это сохранение правил игры для пользователей и обслуживающего персонала. Т.е. вне зависимости от конкретного железа управление инфраструктурой и ее использование требует того же самого опыта.

                      0
                      1) Я об этом и писал. Но вот в статье п1 — экономия на железе. А по факту не на железе, а на удобстве.
                      3) Без конкретной прикладной задачи слова ни о чем. А с конкретной задачей уже надо считать имеет смысл виртуализировать или нет.
                        0
                        1) Купить 120 физических серверов или шесть, на которых будут 120 виртуальных? Это по вашему не экономия на железе? Поверьте опыту, такая степень консолидации — далеко не предел. И вы не об этом писали совсем.

                        3) У меня ощущение возникает, что я сейчас пытаюсь рассказать о преимуществах самобеглой повозки перед гужевым транспортом. Нет, разумеется, есть такие сценарии, когда лошадка будет лучше. Но большая часть потребителей уже предпочла «грузовик».

                          0
                          Проблема то не в самих серверах, а в том что не все приложения смогут захоститься на одном сервере. Хостить несколько приложений на одном сервере выгоднее чем хостить несколько виртуалок, не находите? Тут надо смотреть на конкретные приложения и считать. Но это НЕУДОБНО. А вот закупить железа с запасом раза в 3, а потом виртуализацией нарезать отдельные машины УДОБНО, но не очень эффективно по деньгам. Об этом я писал, а не о том, о чем вы думаете ;)
                            0
                            Проблема то не в самих серверах, а в том что не все приложения смогут захоститься на одном сервере.

                            Таки могут. Называется это контейнерная виртуализация. Пример: Parallels Virtuozo Containers

                            Тут надо смотреть на конкретные приложения и считать. Но это НЕУДОБНО. А вот закупить железа с запасом раза в 3, а потом виртуализацией нарезать отдельные машины УДОБНО, но не очень эффективно по деньгам

                            Неудобно, простите, шубу в трусы заправлять. А считать нужно всегда.

                            Нормальные проекты по виртуализации чего-либо проходят с предварительной оценкой требуемых ресурсов. Погрешность 10-20% в большую сторону. Не в три раза. Читайте про VMware Capacity Planer, например. Про шаринг ресурсов, активную и неактивную память, компрессию и т.п. я вам даже не буду пытаться рассказывать.

                            Об этом я писал


                            Вот о чем вы писали:
                            Частное облако для экономии ресурсов — фейк. Даже наоборот, все эти потуги с виртуализацией увеличивают требования к железу, по сравнению с обычным размещением

                            Это полная ерунда.

                              –2
                              То есть вы таки утверждаете что переход от кусочной виртуализации (как оно обычно бывает) к private cloud позволит что-то сэкономить на железе? За счет чего?
                                +1
                                Где, интересно, я это утверждаю?

                                Виртуализация — да, позволяет экономить на железе (в том числе «кусочная»). См. выше.

                                Частное облако — способ предоставлять «ресурсы как сервис» и брать за это деньги (прозрачно для потребителя). Ресурсами могут быть и аппаратные серверы, и даже преднастроенные кучки оборудования. Вообще без использования серверной виртуализации в принципе.
                                0
                                Коллеги, мне кажется, в пылу беседы, вы немного подзабыли про такие важные вещи, которые сейчас вовсю используются в виртуализации, как механизмы дедупликации данных: области оперативной памяти и жесткого диска, которые содержат одинаковые участки данных, при нехватке ресурсов бъются на более мелкие и вместо того, чтобы хранить одни и те же участки несколько раз, создаются ссылки. Таким образом, используя простую виртуализацию(даже без облачных «докруток» сверху), мы получаем довольно внушительную экономию ресурсов. На счет контейнеров: хотя разработчики делают все, чтобы максимально приблизить среду исполнения к той, что имеется в родной ОС, не все ПО совместимо с технологиями контейнеризации — это все нужно тестировать и проверять. Могу сказать, что, например, не каждое ПО будет успешно работать под тем же виндовым терминальником. Тут то нам, как раз, и приходит на помощь виртуализация со своими «преферансом и куртизанками»(я про дедупликацию и перераспределение ресурсов без прерывания сервиса). Ситуаций, когда такой подход наиболее оптимален море: переходить на другой софт, который будет работать с вашей средой — это не только затраты на лицензии и внедрение, у вас еще и пользователи будут страдать, пока не привыкнут, а это, в свою очередь, хотя и трудноизмеряемые, но убытки. Или же у вас дорогущее специализированное ПО, производитель которого канул в лету вместе со всем саппортом… В этом случае,(как минимум) пока вы не найдете иного решения, вашу систему, находящуюся на издыхании и от которой зависит серьезная доля выручки вашей компании, спасет, с большой долей вероятности, только виртуализация. В общем: про преимущества виртуализации было сказано, а еще больше сделано немало начинаю с того же продукта VMware Server. Если не верится, что земля круглая — дело ваше. Да, согласен, что она бывает плоской, но это в очень редких случаях, когда, например, мы рассматриваем пространство состоящее всего из двух измерений(это не сарказм — в жизни бывают разные ситуации).
                                  0
                                  А я то как под эту раздачу попал? :)
                                    0
                                    Как то оказались вы в одной ветке камментов =)
                                      0
                                      Просто я как бы верю, что земля ээ шарообразная и про все остальное тоже в курсе.
                                        0
                                        Не принимайте на свой счет. А земля, как я написал, иногда бывает и плоская;)
                                          +2
                                          Плоская земля не бывает. И Земля. Вы как-то вообще очень вольно пишете. От контейнеров легко перепрыгиваете к терминальным серверам, дедупликацию причисляете к свойствам виртуализации, в общем вот как раз таким некорректным текстом и рождаете несознательных троллей вроде gandjustas. Без обид.
                                            0
                                            Земля бывает плоской. В двухмерном мире. Просто, я человек не особо любящий категоричность и старающийся смотреть на вещи под разными углами. Живя в нашей чудесной стране, я понял что словосочетание «не бывает» довольно редко соответствует действительности, поэтому, извините, позволяю себе иногда такие вольности. ЕМНИП, терминальный сервер это тоже некий вид контейнеризации(если утрировать). А дедупликация — это дедупликация. Ничьим свойством она не является, но ее использование в виртуализации значительно способствует уплотнению ресурсов. А тролли… «Если что-то может быть понято неверно — оно будет понято неверно» — одна из мудрых вариаций на тему законов Мерфи. Обид никаких, да и изначально в споре я был на вашей стороне, просто мой комментарий был не совсем верно сформулирован/воспринят(нужное подчеркнуть). Так что, поддерживаю ваше чаяние разойтись с миром)
                                              0
                                              В двумерном мире нет земли. И Земли тоже. Это вполне себе реальные объекты реального мира. Вы можете фантазировать на тему проекции шара на плоскость или тому подобного, но не можете говорить «земля бывает плоской». Потому что 1) вы говорите о грунте (верхний обычно плодородный слой планеты Земля); 2) или планете Земля (третья от Солнца планета). В первом случае, в 2D мире нет слоев. Во втором случае, речь о планете, которая суть — «шар». Категоричность и строгость рассуждений — очень разные вещи. Когда вы подменяете понятия, пытаясь найти аналогию или пошутить, сама ценность мысли испаряется, вы путаете сам себя. Это хороший совет, который сильно облегчит общение с серьезными Заказчиками, особенно с гоской.

                                              Терминальный сервер к контейнерам не имеет никакого отношения. Потому что отсутствует ключевой момент — изоляция. Потоковая доставка приложений (ThinApp, часть XenApp, и т.п.) не является терминальной службой, но иногда входит в состав комплекса доставки приложений (тот же XenApp). Вот она, зачастую, изоляцию обеспечивает.

                                              Дедупликация способствует уплотнению ресурсов и в отрыве от виртуализации. Т.е. преимуществом не является. Про VMware TPS рассказывать не надо, а то я вас расстрою.

                                              :) Я за мир, конечно, и за качество контента в блоге уважаемой компании :)
                                                0
                                                Земля(ну, извините, что из-за невнимательности не поставил заглавную букву), приплюснута с полюсов — поэтому, это даже не шар. Ладно, тут зацепились за мою вольную интерпретацию фактов. Ок, убедили — не плоская. А изоляция нынче даже в десктопных осях присутствует(в виде контейнеризации и виртуализации). И чем по вашему «разделение пользовательских пространств» или их «изоляция» не простейший пример контейнеризации? Тут уже все сводится даже не к определениям, а маркетинговым ярлыкам. А про «отрыв от виртуализации» вообще не понятно… Я понимаю, что виртуализация и дедупликация — разные вещи, но, в основном, они идут рука об руку. Про нее я написал, потому что в обсуждении была мысль о перерасходе ресурсов при использовании виртуализации(накладные расходы) и, кстати, поддерживал вашу мысль о том, что они «копеечны». TPS не панацея, но бывают сценарии при которых экономиться до 40% оперативы. Да и не TPSом единым… Не зря VMware купили малоизвестную для нашего обывателя контору под названием Virstro — чтобы еще больше уплотнить ресурсы(тут уже не ОЗУ, а СХД)…
                                                А давайте, мы с вами, если уж на то пошло, придем к единому знаменателю уже в ЛС и резюмируем его здесь? Честно, устал уже.
                                                  0
                                                  Ок, с плоской Землей разобрались.

                                                  И чем по вашему «разделение пользовательских пространств» или их «изоляция» не простейший пример контейнеризации?

                                                  Это отличный пример подмены понятий. Вместо того, чтобы взять определение объекта и подобрать подходящие объекты, вы поступаете ровно наоборот. Берете произвольное множество объектов и пытаетесь подогнать под него уже принятое определение.

                                                  Про дедупликацию даже комментировать не хочется, вы там уже не просто за уши факты притягиваете, вы эти уши уже оторвали и на ногу намотали.

                                                  А давайте, мы с вами, если уж на то пошло, придем к единому знаменателю уже в ЛС и резюмируем его здесь? Честно, устал уже.

                                                  А какой смысл в ЛС? Я не пытаюсь вас исправить, поздно уже. Да и какой смысл искать компромисс между фактом и вымыслом?
                  –3
                  windows detected!

                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                  Самое читаемое