Как стать автором
Обновить
2
0
Дмитрий Яшин @c1airvoyant

Эксперт по миграции в облако

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

Я неоднократно наблюдал, как компании проектируют «тяжелые бомбардировщики», пробуя решить задачу резервирования, при очевидной избыточности такого подхода в конкретном случае, и просто откладывают эту задачу в долгий ящик из-за стоимости проекта. Хотя на самом деле им достаточно было купить готовый, ну или почти готовый, «планер» и немного доработать напильником.
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. Лучше ответить поздно, чем никогда )

Для наших Заказчиков это лишние риски блокировки со стороны РКН, поэтому нет, тор-ноду поставить нельзя.

Загрузка физических процессоров на конкретном хосте — не более 80%, физической памяти на конкретном хосте — не более 90%. По количеству свободных хостов требования разнятся в зависимости от облака (у нас их несколько) и конфигурации оборудования в конкретном кластере виртуализации. Стараемся держать свободными не менее четверти ресурсов конкретного кластера.

На мой взгляд, размещение виртуальных машин у провайдера — это вполне облачная услуга, которой чаще пользуются как раз-таки корпоративные Заказчики. А вот быстро растущие стартапы, как показывает практика, предпочитают покупать свое железо, размещать его в коммерческих датацентрах и развертывать разрабатываемые системы bare-metal. От таких ребят я неоднократно слышал, что для них обеспечивать стабильность и скорость работы своих систем поверх виртуальной инфраструктуры дороже, нежели держать пару свободных хостов на случай отказа.
Впрочем — допускаю, что это только мой избирательный опыт.

Что же касается коренной переработки архитектуры в компаниях, где по 20 (а иногда и по 80) различных ИТ систем используется, то такая дорогостоящая и сложная работа даст большой эффект при размещении как в облаке, так и «на земле».
Ну… на текущий момент указываем таким образом. А как, на ваш взгляд, правильнее указывать? По максимально допустимому пиковому значению?

С трудом верится, что прямо-таки единственным. А как же широкий выбор уже реализованных в AWS инфраструктурных сервисов, как же большое количество встроенных инструментов для разработчиков? И управлять инфраструктурой, вероятно, станет проще, а обслуживать ее — дешевле. Опять же — если стоимость AWS кажется высокой, а бизнес находится в России, рассмотрите отечественных провайдеров. Наверняка получится дешевле, и с колебаниями курсов валют как-то проще.

Сильно зависит от конкретной компании, но в целом да — тенденция ужесточения внутреннего контроля в корпорациях прослеживается, и тендер при выборе облачного провайдера как правило приходится играть. Другое дело, что компании в облако чаще заезжают сразу большим количеством ресурсов. Т.е. сначала берут, условно, на 200 тысяч, а потом по мере необходимости периодически расширяют по 20 уже без тендера.
Тендерную же процедуру просто повторяют периодически — кто-то раз в год, кто-то раз в 3 года, но при этом используют уже готовые тендерные документы с небольшими правками.
Нет, Azure Stack пока опасаемся. Нужно понять динамику и вектор развития платформы — как быстро и в каком объеме сервисы большого Azure будут переноситься в Stack, не останутся ли через год-два обладатели Stack-инсталляций без полноценной поддержки с обновлением функционала и т.п.
По поводу оверселлинга:

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

С технической же точки зрения оверселлинг является неотъемлемой частью многих современных облачных платформ — процессорные ресурсы объединяются в ресурсный пул и раздаются в виде пула гигагерцев Заказчикам. Сопоставление физических и виртуальных ядер используется достаточно редко. Как правило это делается в частных инсталляциях специализированных бизнес-приложений, чтобы сохранить поддержку вендора.

«Честные» ядра нужны в облаках, рассчитанных на корпоративные приложения. В этом случае «честность» обеспечивается контролем предельной утилизации CPU на хосте, мониторингом доступность физического процессора для ВМ (CPU ready), а также, как верно написал Spline, периодическими замерами CPU steal time.

Заказчик вполне может контролировать оверселлинг — либо делая собственные замеры, либо запрашивая графики мониторинга у провайдера.
Нет, машины не в фулл толеранс, к сожалению, т.к. эта технология пока слабо применима в облаках — такое делаем пока только в рамках частной инсталляции. С репликами на разных сайтах проще, но это все-таки уже катастрофоустойчивость, поэтому предлагается в виде платной опции.
Под ресурсами для отказоустойчивости понимаем гарантию наличия ресурсов для работы виртуальных машин при любой поломке. Это достигается резервными свободными хостами в кластерах виртуализации и регламентами по предельной загрузке продуктивного оборудования.
Нет, мы не берем дополнительную плату за траффик. Каких-то лимитов по объему месячного траффика также не устанавливаем. У нас, конечно, есть механизмы защиты от DDoS для внешних и внутренних атак, направленных на переполнение каналов, но если траффик валидный, то не лимитируем. И в целом избегаем каких-то скрытых платежей.
На самом деле размещают практически все — как инфраструктурные системы, так и бизнес-приложения. Многие оставляют у себя на земле только небольшой базовый набор из дополнительного контроллера домена и принт-сервера, а то и просто VPN-шлюзом ограничиваются. У нас как-то был подобный проект — Заказчику нужно было переехать в новый офис, где не было места для серверов вообще — только небольшой шкаф для коммутаторов и пограничного шлюза.
Сильно зависит от ситуации — как давно построена серверная, сколько лет оборудованию и пр. Если свое железо покупалось сравнительно недавно, то отказываться от него не нужно — лучше перевезти его в тот же датацентр, где находится облако выбранного провайдера, и организовать гибрид с облаком. В этом случае вы получите и гибкость облака, и ваше оборудование сможет отработать положенное, после чего также заменится на ресурсы провайдера.
С недавно построенной серверной несколько сложнее, но как вариант — использовать ее в качестве резервной площадки, либо арендовать оптику до облака и также организовать гибрид.

Информация

В рейтинге
Не участвует
Откуда
Москва, Москва и Московская обл., Россия
Зарегистрирован
Активность