Комментарии 47
Это всё хорошо, когда ничего нет. А когда всё уже есть — резервы, серверная и т.д.?
Докупают ещё десяток серверов в свободные юниты и сами становятся «облачным провайдером»
Сильно зависит от ситуации — как давно построена серверная, сколько лет оборудованию и пр. Если свое железо покупалось сравнительно недавно, то отказываться от него не нужно — лучше перевезти его в тот же датацентр, где находится облако выбранного провайдера, и организовать гибрид с облаком. В этом случае вы получите и гибкость облака, и ваше оборудование сможет отработать положенное, после чего также заменится на ресурсы провайдера.
С недавно построенной серверной несколько сложнее, но как вариант — использовать ее в качестве резервной площадки, либо арендовать оптику до облака и также организовать гибрид.
С недавно построенной серверной несколько сложнее, но как вариант — использовать ее в качестве резервной площадки, либо арендовать оптику до облака и также организовать гибрид.
А что вообще переносят в облака? Я имею в в виду какие сервисы? Вряд ли в облака отдают контроллеры домена и прочую инфраструктуру?
Вполне можно и контроллеры домена. В принципе тебя никто не ограничивает. Например у тебя пара офисов — поднимаешь в облаке домен контроллер, поднимаешь до него туннели и все офисы у тебя оказываются в домене. Для резерва можешь поднять еще один домен контроллер в другом облаке и сделать перекрестные туннели.
Видеонаблюдение, например, типа Ivideon, IPeye, Macrosop и т.п (VSaaS). Хранение архивов в облаке, плюс аналитика на облачных серверах. Не требуются ни локальные сервера, ни видеорегистраторы, ни мутки с VPN и т.п. Очень удобно иметь доступ ко всем камерам через один ЛК или мобильное приложение. Особенно для территориально распределенных организаций, торговых сетей и т.п. Очень динамично растет пока этот сегмент.
На самом деле размещают практически все — как инфраструктурные системы, так и бизнес-приложения. Многие оставляют у себя на земле только небольшой базовый набор из дополнительного контроллера домена и принт-сервера, а то и просто VPN-шлюзом ограничиваются. У нас как-то был подобный проект — Заказчику нужно было переехать в новый офис, где не было места для серверов вообще — только небольшой шкаф для коммутаторов и пограничного шлюза.
Практика показывает, что серверы архитектуры x86 не стоит постоянно нагружать более чем на 70-80% по процессору и 80-90% по памяти
Провайдеры очень любят делать оверселлинг на виртуалках т.к. это способ сэкономить на оборудовании. И vmware это очень даже хорошо позволяет делать. Заказчик это никак не отследит.
На тему капитальных затрат на оборудование — никто не мешает брать сервера в аренду, прямо в цодах. И это дешевле IaaS.
На тему дешевизны чужого облака — если ваши ресурсы укладываются в 1-2 железных сервера, то скорее всего у вас уже есть инженер на обслуживание этих ресурсов и переезд в чужое облако никуда этого инженера не денет. И с большой долей вероятности аренда резервного сервера будет стоить дешевле переезда в чужое облако. А в РФ возможно покупка серверов и установка в цоде отобьется уже через год.
Если у вас нету данных которые надо хранить на территории РФ, тогда вам прямой путь в европейские цоды. Они не стремятся окупить все железо за пол года и даже с учетом курса валюты, выделенные серверы там получается существенно дешевле.
Если у вас неравномерная нагрузка, тогда возможно вас спасут железные сервера на чуть выше минимальной нагрузки + для пиков нагрузки можно автоматически брать в аренду виртуалки.
Если у вас вобще неравномерная нагрузка, либо вам не хочется заниматься гибридной инфраструктурой, или не иметь геморроя с железом тогда облака ваш выход.
И не надо считать, что вам не придется периодически искать и решать нетривиальные проблемы — почему у вас так странно ведет себя приложение или трафик у облачного провайдера (у нас например диски от сервера с базой отваливались), кто виноват и что делать.
CPU Steal time. Отслеживание оверселлинга. У меня на AWS до 80% доходило на американском сегменте в конфигурациях, доступных для free tier.
По поводу оверселлинга:
Разные облака рассчитаны для разных задач, поэтому не могу назвать оверселлинг каким-то абсолютным злом. К примеру, если вам нужно разместить не особо нагруженный сайт, то вся мощь ядер вам не нужна, и оверселлинг у провайдера специализированного веб-хостинга позволит купить услугу дешевле.
С технической же точки зрения оверселлинг является неотъемлемой частью многих современных облачных платформ — процессорные ресурсы объединяются в ресурсный пул и раздаются в виде пула гигагерцев Заказчикам. Сопоставление физических и виртуальных ядер используется достаточно редко. Как правило это делается в частных инсталляциях специализированных бизнес-приложений, чтобы сохранить поддержку вендора.
«Честные» ядра нужны в облаках, рассчитанных на корпоративные приложения. В этом случае «честность» обеспечивается контролем предельной утилизации CPU на хосте, мониторингом доступность физического процессора для ВМ (CPU ready), а также, как верно написал Spline, периодическими замерами CPU steal time.
Заказчик вполне может контролировать оверселлинг — либо делая собственные замеры, либо запрашивая графики мониторинга у провайдера.
Разные облака рассчитаны для разных задач, поэтому не могу назвать оверселлинг каким-то абсолютным злом. К примеру, если вам нужно разместить не особо нагруженный сайт, то вся мощь ядер вам не нужна, и оверселлинг у провайдера специализированного веб-хостинга позволит купить услугу дешевле.
С технической же точки зрения оверселлинг является неотъемлемой частью многих современных облачных платформ — процессорные ресурсы объединяются в ресурсный пул и раздаются в виде пула гигагерцев Заказчикам. Сопоставление физических и виртуальных ядер используется достаточно редко. Как правило это делается в частных инсталляциях специализированных бизнес-приложений, чтобы сохранить поддержку вендора.
«Честные» ядра нужны в облаках, рассчитанных на корпоративные приложения. В этом случае «честность» обеспечивается контролем предельной утилизации CPU на хосте, мониторингом доступность физического процессора для ВМ (CPU ready), а также, как верно написал Spline, периодическими замерами CPU steal time.
Заказчик вполне может контролировать оверселлинг — либо делая собственные замеры, либо запрашивая графики мониторинга у провайдера.
1. Не учитываются ресурсы, требуемые для обеспечения отказоустойчивости…
А в облаке как они учтены? В облаке что все машины сразу в фул толеранс? Или облако автоматом для каждой первой машины по две реплики на разных сайтах держит?
Опять взяли за основу кейс аномально быстрорастущего стартапа и пытаются натянуть его на все что движется…
А в облаке как они учтены? В облаке что все машины сразу в фул толеранс? Или облако автоматом для каждой первой машины по две реплики на разных сайтах держит?
Опять взяли за основу кейс аномально быстрорастущего стартапа и пытаются натянуть его на все что движется…
Нет, машины не в фулл толеранс, к сожалению, т.к. эта технология пока слабо применима в облаках — такое делаем пока только в рамках частной инсталляции. С репликами на разных сайтах проще, но это все-таки уже катастрофоустойчивость, поэтому предлагается в виде платной опции.
Под ресурсами для отказоустойчивости понимаем гарантию наличия ресурсов для работы виртуальных машин при любой поломке. Это достигается резервными свободными хостами в кластерах виртуализации и регламентами по предельной загрузке продуктивного оборудования.
Под ресурсами для отказоустойчивости понимаем гарантию наличия ресурсов для работы виртуальных машин при любой поломке. Это достигается резервными свободными хостами в кластерах виртуализации и регламентами по предельной загрузке продуктивного оборудования.
А можно узнать какой лимит резервных свободных хостов и какие нормативы по предельной загрузке в вашем облаке?
Загрузка физических процессоров на конкретном хосте — не более 80%, физической памяти на конкретном хосте — не более 90%. По количеству свободных хостов требования разнятся в зависимости от облака (у нас их несколько) и конфигурации оборудования в конкретном кластере виртуализации. Стараемся держать свободными не менее четверти ресурсов конкретного кластера.
Например 6 серверов
www.ovh.ie/dedicated_servers/enterprise/1801sp94.xml
1000+ евро
И ваш калькулятор на 2000+ евро
девопс/сисадмин мне будет нужен в любом случае.
Резерв мощностей в OVH (в сравнении с ресурсами в облаке) у меня х6 по процессору и примерно х3 по памяти
Вы можете это как-то прокомментировать?
www.ovh.ie/dedicated_servers/enterprise/1801sp94.xml
1000+ евро
И ваш калькулятор на 2000+ евро
девопс/сисадмин мне будет нужен в любом случае.
Резерв мощностей в OVH (в сравнении с ресурсами в облаке) у меня х6 по процессору и примерно х3 по памяти
Вы можете это как-то прокомментировать?
IaaS и выделенные серверы — это все-таки разные услуги. Если не сравнивать конфигурацию именно железа, то основное различие — в зоне ответственности провайдера. OVH в рамках данной услуги следит только за работоспособностью самого железного сервера и доступности его сетевых интерфейсов по сети, а его настройка, защита периметра, организация нужной архитектуры сети и пр. уже ложится на ваши плечи. В то время как в IaaS вам не нужно думать о слое железа вовсе, и вместе с пулом облачных ресурсов вы получаете полноценную виртуализацию сетей, где можно любым образом нарезать подсети, есть кластеризованный виртуальный роутер на периметре с полным набором сервисов (FW, NAT, site-to-site VPN, client-to-site VPN и пр.), продвинутый балансировщик внешних и внутренних запросов, система мониторинга, широкий функционал подготовки шаблонов, гибкое управление через API и другие сервисы, доступные по умолчанию и включенные в стоимость.
Услуги сильно отличаются и по отказоустойчивости. Я допускаю, что в OVH хорошая система бекапирования, и при отказе арендованного железного сервера они выделят другой и накатят на него бекап — вопрос, сколько времени это займет, и будет ли, к примеру, дневной бекап актуален для вашего сервиса? В облаке при жестком отказе хоста размещенные на нем ВМ будут лишь перезагружены, а если хост просто деградировал, то машинки будут мигрированы без ребута.
Если же говорить именно о железе, то в облаке VMware, которое на скриншоте, используются процессоры Xeon E5-2697A v4, которые быстрее работают с памятью, обладают более высокой производительностью из расчета на ядро, чем Xeon E5-1660 v3, а также позволяют выдать вашему серверу значительно большее кол-во ядер, т.к. многим нагруженным аппликейшенам, серверам баз данных, OLAP-кубам или процессинговым молотилкам просто не хватит 8 ядер Xeon E5-1660 v3.
Что же касается стоимости, то в случае с OVH цена указана без НДС, а в калькуляторе — с НДС, что делает реальную разницу меньше. Плюс, с объемом более 100 т.р. вы уже можете рассчитывать на скидку, и также сможете снизить объем платежа за счет предоплаты.
P.S. Лучше ответить поздно, чем никогда )
Услуги сильно отличаются и по отказоустойчивости. Я допускаю, что в OVH хорошая система бекапирования, и при отказе арендованного железного сервера они выделят другой и накатят на него бекап — вопрос, сколько времени это займет, и будет ли, к примеру, дневной бекап актуален для вашего сервиса? В облаке при жестком отказе хоста размещенные на нем ВМ будут лишь перезагружены, а если хост просто деградировал, то машинки будут мигрированы без ребута.
Если же говорить именно о железе, то в облаке VMware, которое на скриншоте, используются процессоры Xeon E5-2697A v4, которые быстрее работают с памятью, обладают более высокой производительностью из расчета на ядро, чем Xeon E5-1660 v3, а также позволяют выдать вашему серверу значительно большее кол-во ядер, т.к. многим нагруженным аппликейшенам, серверам баз данных, OLAP-кубам или процессинговым молотилкам просто не хватит 8 ядер Xeon E5-1660 v3.
Что же касается стоимости, то в случае с OVH цена указана без НДС, а в калькуляторе — с НДС, что делает реальную разницу меньше. Плюс, с объемом более 100 т.р. вы уже можете рассчитывать на скидку, и также сможете снизить объем платежа за счет предоплаты.
P.S. Лучше ответить поздно, чем никогда )
Например, если покупаем 5 серверов с 40 процессорными ядрами и 256 ГБ RAM, то и у облачного провайдера запрашиваем аналогичные ресурсы (40*5=200 vCPU + 256*5=1280 ГБ vRAM)
это как у вас вышло 5*40 полновесных ядер = 200 vCPU !? vCPU у амазона и гугла это hardware thread, а не то что вы подумали.
А трафик у вас, как в Амазоне, в 3-4 раза дороже?
Нет, мы не берем дополнительную плату за траффик. Каких-то лимитов по объему месячного траффика также не устанавливаем. У нас, конечно, есть механизмы защиты от DDoS для внешних и внутренних атак, направленных на переполнение каналов, но если траффик валидный, то не лимитируем. И в целом избегаем каких-то скрытых платежей.
Насчёт бюджетов в корпорациях: если покупка или аренда серверов требует тендеров и много месячных согласований, то и выбор облачного провайдера их потребует, причём тендер проводить каждый раз при увеличении ресурсов, а не так что один раз согласовал на 1000 в месяц, а потом молча оплачивают счёта на миллион.
Сильно зависит от конкретной компании, но в целом да — тенденция ужесточения внутреннего контроля в корпорациях прослеживается, и тендер при выборе облачного провайдера как правило приходится играть. Другое дело, что компании в облако чаще заезжают сразу большим количеством ресурсов. Т.е. сначала берут, условно, на 200 тысяч, а потом по мере необходимости периодически расширяют по 20 уже без тендера.
Тендерную же процедуру просто повторяют периодически — кто-то раз в год, кто-то раз в 3 года, но при этом используют уже готовые тендерные документы с небольшими правками.
Тендерную же процедуру просто повторяют периодически — кто-то раз в год, кто-то раз в 3 года, но при этом используют уже готовые тендерные документы с небольшими правками.
Есть Azure Stack?
Нет, Azure Stack пока опасаемся. Нужно понять динамику и вектор развития платформы — как быстро и в каком объеме сервисы большого Azure будут переноситься в Stack, не останутся ли через год-два обладатели Stack-инсталляций без полноценной поддержки с обновлением функционала и т.п.
Да, мы еще помним про Azure Pack, последнее обновления для которого вышло года полтора назад, хотя обещали поддержку аж до 2027 года. Еще про Azure Stack надо помнить, что там довольно высокие CAPEX и OPEX. Ценник для конечного клиента, вероятно, будет просто огромный, дороже чем в Microsoft Azure. Вот тут можно посмотреть стоимость лицензий.
А как обстоят дела с ИБ. Любая служба корпоративной защиты завернет все облака на свои сервера.
1. Не любая.
2. Есть облака, сертифицированные по всяким разным стандартам типа PCI DSS, БиоПД, ФСТЭК и т.д. Причем свой ДЦ еще тоже надо сертифицировать, что непросто и небыстро.
3. Для параноид-режима, типа крупных банков, возможно физическое огораживание стоек в ДЦс автоматчиками по периметру. Хотя это уже не облака, а колок/аренда.
2. Есть облака, сертифицированные по всяким разным стандартам типа PCI DSS, БиоПД, ФСТЭК и т.д. Причем свой ДЦ еще тоже надо сертифицировать, что непросто и небыстро.
3. Для параноид-режима, типа крупных банков, возможно физическое огораживание стоек в ДЦ
Прямо сейчас я участвую в планировании миграции из собственного датацентра в aws. По самым оптимистичным прикидкам за aws придется платить минимум в 2.5 раза больше, чем за собственный датацентр. Опытные люди говорят, что финальная разница будет еще больше. При этом единственный весомый плюс от миграции будет мгновенная доступность новых машин когда они понадобятся.
С трудом верится, что прямо-таки единственным. А как же широкий выбор уже реализованных в AWS инфраструктурных сервисов, как же большое количество встроенных инструментов для разработчиков? И управлять инфраструктурой, вероятно, станет проще, а обслуживать ее — дешевле. Опять же — если стоимость AWS кажется высокой, а бизнес находится в России, рассмотрите отечественных провайдеров. Наверняка получится дешевле, и с колебаниями курсов валют как-то проще.
Бизнес не в России, так что отечественные провайдеры не вариант. Широкий выбор сервисов aws, как я уже писал выше, надо использовать осторожно, чтобы не попасть в ситуацию с vendor locking. Предварительный опыт использования инфраструктуры aws продемонстрировал, что там хватает своих нюансов, не все так замечательно, как в рекламных проспектах.
Большинство инфраструктурных сервисов AWS требуют заточки кода приложения под них. А без этого, использование aws в режиме «хост для виртуалок/контейнеров» реально дорого.
Вы не учли, что при переносе существующих решений в облако без коренной переработки архитектуры мы получаем самый обыкновенный хостинг у провайдера, и тут нет ничего от облаков. Выгода этого варианта сомнительна. Используется как раз при быстром наращивании мощностей стартапов или как временная мера при гибридном решении, пока не приехали сервера в свою серверную.
Для получения экономической выгоды от облаков необходимо часто в корень перерабатывать архитектуру всей инфраструктуры. Тут речь не о корпоративном портале или веб сайте компании, а о кейсах когда у компании 20+ различных решений используется. Переработка архитектуры будет стоить дороже чем выгода от экономии серверов или своей новой серверной. Окупится, может быть, через пять лет. Инвестиции на такой период с такими высокими рисками внедрения бизнес не любит.
Staff OpEx уже занимает серьезную долю бюджета и, не редко, даже людей быстро нанять сложнее чем купить сервера :)
Подпишусь под каждым словом. И добавлю, что надо менять менталитет разработчиков на тему экономии ресурсов. Нужно сделать эксперимент — поднял сервер, проверил, что надо, отдал сервер. Потому как я сейчас наблюдаю картину, когда на собственной инфраструктуре вирртуализации заброшенный тестовый сервер может крутиться годами. Ну и еще надо думать о vendor locking, хотя возможно это больше относится к провайдерам типа гугла и амазона.
На мой взгляд, размещение виртуальных машин у провайдера — это вполне облачная услуга, которой чаще пользуются как раз-таки корпоративные Заказчики. А вот быстро растущие стартапы, как показывает практика, предпочитают покупать свое железо, размещать его в коммерческих датацентрах и развертывать разрабатываемые системы bare-metal. От таких ребят я неоднократно слышал, что для них обеспечивать стабильность и скорость работы своих систем поверх виртуальной инфраструктуры дороже, нежели держать пару свободных хостов на случай отказа.
Впрочем — допускаю, что это только мой избирательный опыт.
Что же касается коренной переработки архитектуры в компаниях, где по 20 (а иногда и по 80) различных ИТ систем используется, то такая дорогостоящая и сложная работа даст большой эффект при размещении как в облаке, так и «на земле».
Впрочем — допускаю, что это только мой избирательный опыт.
Что же касается коренной переработки архитектуры в компаниях, где по 20 (а иногда и по 80) различных ИТ систем используется, то такая дорогостоящая и сложная работа даст большой эффект при размещении как в облаке, так и «на земле».
Давать Storage SLA по средней latency — дурной тон. На Хабре было значительное количество статей, почему.
Ну… на текущий момент указываем таким образом. А как, на ваш взгляд, правильнее указывать? По максимально допустимому пиковому значению?
Service Level Indicator — величина latency, а Target — попадание в этот определенную границу не менее определенного процента случаев. Обычно проблемы создает длинный хвост в распределении IO latency. То есть пример хорошего SLT — latency менее 5 мс для 99% запросов.
У вас среднее может быть 3 мс, но если в хвосте хотя бы 1-2% влетают из 200-300 мс это может стать причиной разрыва сессий для некоторых приложений.
У вас среднее может быть 3 мс, но если в хвосте хотя бы 1-2% влетают из 200-300 мс это может стать причиной разрыва сессий для некоторых приложений.
Я считаю, что плохой тон для компании увольнять хорошего специалиста, по случаю миграции в облако серверов компании. Но если его не увольнять, то экономия сомнительная получается. Обычно такой сотрудник начинает выполнять другую работу без увольнения. Поэтому ФОТ лучше не считать. Ну, а если ФОТ не считать, то и экономический профит облака теряется.
Если человек начинает делать новую полезную работу, не связанную с администрированием инфры и виртуализации, то почему же считать его ФОТ? Ну или тогда уж добавлять новую штатку в обоих случаях…
Если человек начинает делать новую работу, то его ФОТ вычитается из расходов на администрирование серверов и прибавляется к расходам на что-то другое, пускай даже на «поддержание лояльности более ненужных сотрудников».
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
7 типичных ошибок при сравнении своих серверов с облаком