Обновлен прайс-лист актуальных и востребованных серверов на 2019 год.
Добавлены цены в EUR и BTC.



Для заказа обращайтесь на sales@abcd.host
Либо через тикет в личном кабинете: panel.abcd.host/billmgr

Управление Kubernetes над Kubernetes было хорошей идеей для компонентов без контроля состояния плоскости управления… но как насчет etcd?


В нашем предыдущем посте мы описали архитектуру Kubinception, как мы запускаем Kubernetes над Kubernetes для компонентов без состояний в плоскостях управления кластерами клиентов. Но как насчет компонента с состоянием, etcd?

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

Самая простая идея не всегда хорошая
Первый подход заключается в простом следовании логике Kubinception: для каждого клиентского кластера развертывание кластера etcd в качестве модулей, работающих на административном кластере.


Этот полный подход Kubinception имеет преимущество быть простым, он кажется продолжением того, что мы делаем с компонентами без сохранения состояния. Но если взглянуть на него подробно, он показывает свои недостатки. Развертывание кластера etcd не так просто и просто, как развертывание без сохранения состояния и является критически важным для работы кластера, мы не могли просто обработать его вручную, нам был необходим автоматизированный подход для управления им на более высоком уровне. www.diycode.cc/projects/coreos/etcd-operator

Использование оператора
Мы были не единственными, кто думал, что сложность работы с развертыванием и работой кластера etcd на Kubernetes была чрезмерной, люди из CoreOS заметили это, и в 2016 году они выпустили элегантное решение проблемы: etcd оператор coreos.com/blog/introducing-the-etcd-operator.html

Оператор — это специальный контроллер, который расширяет API Kubernetes для простого создания, настройки и управления экземплярами сложных (часто распределенных) приложений с отслеживанием состояния в Kubernetes. Для записи, понятие оператора было введено CoreOS с оператором etcd.


Оператор etcd управляет кластерами etcd, развернутыми в Kubernetes, и автоматизирует рабочие задачи: создание, уничтожение, изменение размера, аварийное переключение, непрерывное обновление, резервное копирование
kubernetes.io

Как и в предыдущем решении, кластер etcd для каждого клиентского кластера развертывается в качестве модулей в административном кластере. По умолчанию оператор etcd развертывает кластер etcd, используя локальное непостоянное хранилище для каждого модуля etcd. Это означает, что если все модули умирают (маловероятно) или перепланируются и появляются в другом узле (гораздо более вероятно), мы можем потерять данные etcd. А без этого заказчик Kubernetes оказывается в кирпиче.

Оператор etcd может быть настроен на использование постоянных томов (PV) для хранения данных, поэтому теоретически проблема была решена. Теоретически, поскольку управление томами не было достаточно зрелым, когда мы тестировали его, и если модуль etcd был убит и переназначен, новый модуль не смог получить свои данные на PV. Таким образом, риск полной потери кворума и блокирования клиентского кластера все еще был у оператора etcd.
kubernetes.io/docs/concepts/storage/persistent-volumes/

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

StatefulSet
Помимо оператора, другим решением было использование StatefulSet, своего рода распределенного развертывания, хорошо подходящего для управления распределенными приложениями с отслеживанием состояния.
kubernetes.io/docs/concepts/workloads/controllers/statefulset/
kubernetes.io/docs/concepts/workloads/controllers/deployment/
github.com/helm/charts/tree/master/incubator/etcd

Существует официальная диаграмма ETCD Helm, которая позволяет развертывать кластеры ETCD в виде StafefulSets, которая обменивает некоторую гибкость оператора и удобство для пользователя на более надежное управление PV, которое гарантирует, что перепланированный модуль etcd будет получать свои данные.


Etcd StatefulSet менее удобен, чем оператор etcd, поскольку он не предлагает простого API для операций, таких как масштабирование, отработка отказа, последовательное обновление или резервное копирование. Взамен вы получаете некоторые реальные улучшения в управлении PV. StatefulSet поддерживает липкую идентификацию для каждой записи etcd, и этот постоянный идентификатор сохраняется при любом перепланировании, что позволяет просто связать его с PV.

Система настолько устойчива, что даже если мы потеряем все модули etcd, когда Kubernetes перепланирует их, они найдут свои данные, и кластер продолжит работать без проблем.

Постоянные объемы, задержка и простой расчет затрат
Etcd StatefulSet казался хорошим решением… пока мы не начали интенсивно его использовать. В etcd StatefulSet используются PV, то есть тома сетевого хранилища. И т.д.DD довольно чувствительны к задержке в сети, ее производительность сильно ухудшается, когда сталкивается с задержкой.

Даже если задержку можно держать под контролем (и это очень важно), чем больше мы думаем об этой идее, тем больше она кажется дорогостоящим решением. Для каждого клиентского кластера нам нужно будет развернуть три модуля (фактически удваивая количество модулей) и три связанных PV, это плохо масштабируется для управляемой службы.

В сервисе OVH Managed Kubernetes мы выставляем счета нашим клиентам в соответствии с количеством рабочих узлов, которые они используют, то есть плоскость управления свободна. Это означает, что для обеспечения конкурентоспособности сервиса важно держать под контролем ресурсы, потребляемые плоскостями управления, поэтому нет необходимости удваивать количество пакетов с помощью etcd.

С Kubinception мы пытались мыслить нестандартно, казалось, что для etcd нам нужно было выбраться из этой коробки еще раз.

Мультитенантный кластер etcd
Если мы не хотели развертывать etcd внутри Kubernetes, альтернативой было бы развернуть его снаружи. Мы решили развернуть мультитенантный кластер etcd на выделенных серверах. Все клиентские кластеры будут использовать один и тот же ETCD, каждый сервер API получает свое место в этом мультитенантном кластере etcd.



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

Что дальше?
В следующих статьях из серии Kubernetes мы углубимся в другие аспекты построения OVH Managed Kubernetes и дадим клавиатуру некоторым из наших бета-клиентов, чтобы рассказать о своем опыте использования сервиса.

На следующей неделе давайте сосредоточимся на другой теме, мы разберемся с языком запросов TSL, и почему мы его создали и открыли

Управление выпусками на корпоративном программном обеспечении — непростая задача: обновлять инфраструктуры, справляться со страхом, что редактор программного обеспечения не будет поддерживаться, обновлять лицензии для обеспечения совместимости с новыми версиями и принимать все меры предосторожности для отката, если что-то не работает, как ожидается…

С OVH Private Cloud мы избавим вас от этой сложности. Мы справляемся с этим дорогостоящим и напряженным аспектом, чтобы вы могли сосредоточиться на своем бизнесе и своем производстве.

Но это не значит, что это не проблема для нас.

Обновление сотен vSphere 5.5 до 6.0
vSphere является ведущим продуктом предложения Private Cloud, входящего в пакет SDDC, предоставляемый VMware. vSphere — это программное обеспечение, позволяющее пользователю управлять своими хостами, хранилищем, сетью… С помощью клиента он может создавать кластеры с этими ресурсами для надежного, стабильного и высокодоступного хостинга.

С сентября 2018 года vSphere (vCenter, ESXi…) версии 5.5 прекращает поддержку VMware. Владея безопасностью и стабильностью инфраструктур частного облака, мы начали процессы обновления для всех vCenter.


У нас было около 850 vCenter в версии 5.5 в производстве, что представляет собой значительную работу по обновлению всего, если это было сделано вручную. Но в OVH у нас есть общий лейтмотив: автоматизировать все действия человека для повышения эффективности и избежать ошибок.

Вот так нам удалось обновить 850 vCenter с версии 5.5 до 6.0 за 4 недели. Другими словами, более 210 vCenter в неделю, 30 vCenter в день, с командой из 10 человек, которые следят за этим обслуживанием в фоновом режиме, не оказывая никакого влияния на производительность клиентов.


Наша команда разработчиков разработала и создала набор сценариев (которые мы называем внутренне «роботом») для автоматизации обновлений vCenter несколько лет назад. Этот робот сильно развился с момента появления продукта Private Cloud и следует за нами с версии 4.1 до 6.5, которая находится в стадии разработки.

Мы столкнулись с множеством проблем при настройке автоматических действий, таких как повреждение базы данных, сервисы, не интегрированные в единый вход (им было очень сложно управлять в версии 5.0 и 5.1), а также отпечаток, который не был обновлен для всех сервисов., очень трудно устранить неполадки и воспроизвести его. У нас даже были некоторые операционные системы, которые блокировали обновление программного обеспечения, делая все жестоко остановленным.

Наши рабочие команды много работали со службой поддержки VMware, чтобы найти обходные пути для возникающих проблем и автоматизировать их с помощью команды разработчиков. Это привело к созданию VMware KB, чтобы уведомлять клиентов о проблемах, с которыми мы столкнулись, и которые были признаны VMware ошибками. Команды провели много ночей, чтобы обеспечить минимальное влияние доступности vSphere для клиентов.

Обновление апгрейдер: новая версия робота
Все эти проблемы убеждают нас действовать по двум причинам. Во-первых, добавьте новую версию робота обновления, создавая меньше ошибок, обеспечивая более быстрое выполнение с точки зрения клиента, более надежный и надежный. Во-вторых, мы отказались от процесса обновления по умолчанию, используя обновление программного обеспечения VMware, для решения, в котором мы начинаем с недавно установленного обновленного стека vCenter, на обновленной виртуальной машине, а затем повторно подключаем все компоненты (база данных, NSX…) к этому новому vCenter.

Это значительно улучшило стабильность нашего сервиса, поскольку мы гарантируем, что у нас есть новая исправная и обновленная база для vCenter. Все это резко сократило количество вмешательств наших SRE в инфраструктуру частного облака.

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


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


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


Подводя итог, мы перешли от необходимости автоматизации операции обновления vCenter, которая должна занимать не менее 12 часов на vCenter, к первой версии автоматизации, которая позволяет выполнить эту операцию за 4 часа, но с слишком высокий уровень ошибок (20%) из-за повторяющихся ошибок, которые должны были быть исправлены SRE вручную. Теперь вторая версия является надежной, надежной и стабильной, избегая известных проблем и создавая только редкие и уникальные проблемы, которые будут исправлены в автоматизации за кураторский проход.

Что дальше?
В последующие месяцы последуют другие виды обслуживания, обновления хоста с версии 5.5 до 6.0, обновления нашего варианта резервного копирования Veeam с версии 8.0 до 9.5, обновления нашего варианта Zerto с 5.0 до 5.5 и множество других обновлений наших внутренних машин. обеспечить процедуру аудита PCI-DSS.

Мы будем сохранять ту же прозрачность и общение, прислушиваясь к вашим отзывам и улучшая нашу систему обслуживания.

Согласно прогнозам IDC, расходы на приобретение искусственного интеллекта и когнитивных систем в период до 2022 года составят 77,6 млрд долларов. Эти инвестиции в основном пойдут на пользу индустрии программного обеспечения, в частности, разработке диалоговых приложений, машинного обучения и решений для глубокого обучения. Чтобы отреагировать на эти новые применения, OVH собрала полный спектр решений для поддержки своих клиентов в их различных проектах в области искусственного интеллекта.

OVH делает новый шаг в сотрудничестве с NVIDIA, став первым европейским облачным провайдером, ставшим проверенным партнером платформы для NVIDIA GPU Cloud (NGC). Это укрепляет его позиции в качестве основного участника процесса демократизации технологий искусственного интеллекта.

Пользователи OVH теперь могут запускать программное обеспечение из реестра контейнеров NGC, который предоставляет полный каталог программного обеспечения AI, оптимизированного для графических процессоров NVIDIA, в инфраструктуре OVH. Клиенты OVH могут развернуть проекты по искусственному интеллекту, ускоренной обработке данных и высокопроизводительным вычислениям в облачной инфраструктуре OVH за считанные минуты благодаря программному обеспечению plug and play, доступному от NGC.

«NVIDIA и OVH имеют общую цель — сделать ИИ более доступным и простым в использовании», — сказал Серж Паларик, вице-президент по развитию корпоративного бизнеса, NVIDIA. «Используя оптимизированное для GPU программное обеспечение от NGC на экземплярах NVIDIA GPU и серверы
NVIDIA DGX-1 с открытым исходным кодом в облачной инфраструктуре OVH, пользователи могут быстро запускать и запускать свои проекты ИИ с невероятной производительностью».

Запуск программного обеспечения от NGC в инфраструктуре OVH дополняет существующий в OVH спектр предложений на базе графических процессоров NVIDIA:

• Общедоступные облачные серверы на базе новейших графических процессоров NVIDIA Tesla V100 предлагают отличное соотношение цены и производительности и особенно подходят для стартапов.
• Выделенный пул серверов NVIDIA DGX-1, каждый из которых включает в себя восемь графических процессоров NVIDIA V100 Tensor Core последнего поколения, связанных с технологией NVLink, специально разработан для машинного обучения и глубокого обучения.

Различные варианты использования для разных клиентов
Новые предложения были добавлены в дополнение к большому каталогу данных OVH. Например, OVH Metrics — это специальное предложение IoT, а платформа данных OVH Analytics позволяет развертывать кластеры Hadoop всего за несколько минут.

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

Systran, мировой лидер в области переводческих технологий более 50 лет, также использовал инфраструктуру OVH для интенсивного расчета нейронных сетей, применяемых для более чем 40 языков. Революционная вычислительная производительность системы NVIDIA DGX-1 для искусственного интеллекта позволила Systran индустриализировать производство, а также обучить и обновить более 200 общих и специфических моделей перевода.

Все улучшенное облако OVH
В OVH искусственный интеллект — это не только продукты, но и внутреннее использование, чтобы предоставить клиентам OVH максимально беспроблемный и безопасный опыт.

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

www.soyoustart.com/ie/offers/1801sys481.xml

Вы слышали, что это место — облако. Запускайте корпоративные приложения или масштабируйте свой стартап. Это просто, легко начать и недорого.

Вы переходите на AWS, Azure, Google или, возможно, Digital Ocean. Вы регистрируетесь, и всего за несколько долларов (евро, фунты, выберите валюту) у вас есть работающие серверы и еще тысяча сервисов в вашем распоряжении.

Ваша мечта сбылась, и вы можете обслуживать своих пользователей и пожинать плоды.

К сожалению, вскоре вы понимаете, что вашим корпоративным приложениям действительно требуются огромные объемы памяти и вычислительная мощность (просто проверьте требования к SAP HANA ).

Или, может быть, ваш стартап берет с нуля, и вы получаете все больше и больше пользователей. Попасть в первый миллион пользователей — это весело, а второй — еще лучше, и все больше людей приходит.

Но как только пользователи попадают на ваши серверы, ваш облачный провайдер очень сильно бьет по вашему банковскому счету.

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

Что случилось с бережливым стартапом?
Тратить $ 150 000 на серверы каждый год, уже не выглядит слишком скудно.
Что бы вы сделали, если бы вместо этого потратили эти 150 тысяч долларов на ускорение роста?

И корпоративные приложения, они должны были увеличить ваш доход, не слишком сильно сказываясь на вашей прибыли. Может быть, еще 150 тысяч долларов помогут вашей команде по продажам привлечь еще больше клиентов?

Иногда у вас даже не так много пользователей, но вы просто собираете столько данных, а затем добываете их для соответствующих бизнес-сигналов. Большие данные требуют столько же инфраструктуры, но только менее 10% из них действительно полезны.

Вы можете сделать лучше? Можете ли вы расти, прежде чем закончатся деньги? Разве не было бы неплохо, если бы вы потратили 150 000 долларов на улучшение своего бизнеса, а не бросали их в Amazon, Google или Microsoft?

Это именно то, что мы сделали с некоторыми из наших клиентов.

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

Мы оценили их требования и разработали следующую инфраструктуру:

• Балансировщик нагрузки — 1 сервер, 4 потока, 30 ГБ ОЗУ
• Обслуживание миллионов изображений — 1 сервер, 8 потоков, 120 ГБ ОЗУ, 4 ТБ диска
• Front-end — 2 сервера, 4 потока, 30 ГБ ОЗУ
• Бэк-энд, длительные задачи — 2 сервера, 4 потока, 30 ГБ ОЗУ
• Внутреннее кэширование (Redis) — 1 сервер, 2 потока, 30 ГБ ОЗУ
• База данных — 6 серверов, 4 потока, 240 ГБ оперативной памяти, 1 ТБ диска
• Поиск — 1 сервер, 4 потока, 30 ГБ оперативной памяти
• Серверная часть, сервисы изображений — 1 сервер, 4 потока, 60 ГБ ОЗУ
• Хранение, резервное копирование базы данных, резервное копирование изображений — 6 ТБ
• Трафик — 12 ТБ

Все серверы должны быть виртуальными машинами. Конечно, есть дополнительные средства автоматизации и программное обеспечение, чтобы все это работало и предотвращало значительные простои.

Эта система работает уже несколько лет, и каждый месяц она обслуживает более 5 миллионов пользователей, обслуживая миллионы изображений и другого контента общим объемом около 12 ТБ трафика каждый месяц.

В крайне редком случае сбоя виртуальной машины из-за аппаратного сбоя или по другим причинам система была очень устойчивой, и это приводило к минимальному или отсутствию простоев платформы.

Теперь вы знаете, что нам нужно было запустить и поддерживать. Следующий шаг — решить, где его запустить.

Давайте посмотрим на некоторые варианты и оценим их

• Amazon Web Services
• Microsoft Azure
• Google Cloud
• Цифровой океан
• OVH

Для каждого из этих вариантов, вот основные страницы цен
aws.amazon.com/ec2/pricing/
azure.microsoft.com/en-us/pricing/details/virtual-machines/linux/
cloud.google.com/compute/pricing
www.digitalocean.com/pricing/
www.ovh.com/world/public-cloud/instances/prices/
www.ovh.com/world/dedicated-servers/infra/
Я знаю, что есть другие провайдеры, такие как, например, IBM и Oracle, но цель не в том, чтобы быть обширным, а просто показать вам, что возможно.

AWS

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

Давайте посмотрим на инфраструктуру, которая отвечает требованиям и ее цене.

• Балансировщик нагрузки — 1 сервер r5a.xlarge, 4 потока, 32 ГБ ОЗУ, $ 162,76
• Изображения — 1 сервер r5a.4xlarge, 16 потоков, 128 ГБ ОЗУ, $ 650,88 + 400 долл. EBS
• Front-end — 2 сервера r5a.xlarge, 4 потока, 32 ГБ ОЗУ, $ 325,52
• Внутренние, длительные задачи — 2 сервера r5a.xarge, 4 потока, 32 ГБ оперативной памяти, $ 325,52
• Внутреннее кеширование — 2 сервера r5a.xlarge, 4 потока, 32 ГБ оперативной памяти, $ 325,52
• База данных — 6 серверов r4.8xarge, 32 потока, 244 ГБ ОЗУ, $ 9192,96 + 400 долл. EBS
• Поиск — 1 сервер r5a.xlarge, 4 потока, 32 ГБ оперативной памяти, $ 162,76
• Back-end, сервисы изображений — 1 r5a.2 большой сервер, 4 потока, 64 ГБ оперативной памяти, $ 414,72
• Хранение, резервное копирование базы данных, резервное копирование образов — 6 ТБ, $ 138 на S3
• Трафик — 12 ТБ, $ 1080

На момент написания этой статьи общая стоимость инфраструктуры составила бы 14633,88 долларов в месяц.

Давайте посмотрим на несколько вопросов.

• Можем ли мы стать дешевле, сделав предоплату?
• Да, мы могли бы, и мы можем сделать это для всех облачных провайдеров в этом списке. Однако у этого есть один недостаток, который стоит довольно много заранее.
• Разве это не было бы более экономически эффективным, если бы мы использовали серверные или другие управляемые услуги?

Мы сделали этот расчет, и ответ был, что это не так. В этом случае это было намного дороже.

Azure
В зависимости от того, как вы это оцениваете, Azure может быть больше, чем AWS, или может быть вторым.
Во всех случаях это очень популярно.

• У них также есть тонны сервисов, почти такие же, как AWS, и несколько уникальных.
• Мы использовали их раньше, и мы были приятно удивлены простотой использования.

Давайте посмотрим на инфраструктуру, которая отвечает требованиям и ее цене.

• Балансировщик нагрузки — 1 сервер A4m v2, 4 потока, 32 ГБ ОЗУ, $ 151,84
• Изображения — 1 сервер E16 v3, 16 потоков, 128 ГБ ОЗУ, $ 776,72 + $ 450,56, управляемый диск 4 ТБ
• Front-end — 2 сервера A4m v2, 4 потока, 32 ГБ ОЗУ, $ 303,68
• Внутренние, длительные задачи — 2 сервера A4m v2, 4 потока, 32 ГБ ОЗУ, $ 303,68
• Внутреннее кэширование (Redis) — 1 сервер A4m v2, 4 потока, 32 ГБ ОЗУ, $ 151,84
• База данных — 6 серверов E32 v3, 4 потока, 256 ГБ ОЗУ, $ 9320,64 + 491,52 $ Управляемый диск (4x1 ТБ)
• Поиск — 1 сервер A4m v2, 4 потока, 32 ГБ оперативной памяти, $ 151,84
• Серверная часть, сервисы изображений — 1 сервер A8M v2, 8 потоков, 64 ГБ ОЗУ, $ 319,01
• Хранилище, резервное копирование базы данных, резервное копирование образов — 6 ТБ, $ 110,4 на хранилище Azure
• Трафик — 12 ТБ, 1044 $

На момент написания этой статьи общая стоимость инфраструктуры составила бы 13575,53 долл. США в месяц. Это примерно на 1000 долларов в месяц меньше, чем в AWS, неплохо.

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

Google Cloud
Чрезвычайно известное имя, отличная технология, но с точки зрения размера ему не хватает далеко позади AWS и Azure, и он растет медленнее, чем они. Я не уверен, что это даже на третьем месте.

Я использовал их раньше, и у меня есть только хорошие слова, чтобы сказать об их технологии. В частности, у них есть собственная международная высокоскоростная сеть.

Давайте посмотрим на инфраструктуру, которая отвечает требованиям и ее цене.

• Балансировщик нагрузки — 1 сервер n1-highmem-4, 4 потока, 26 ГБ ОЗУ, $ 121,00
• Обслуживание миллионов изображений — 1 сервер n1-standard-32, 32 потока, 120 ГБ ОЗУ, $ 776,72 и $ 1600 4 ТБ постоянного диска
• Front-end — 2 сервера n1-highmem-4, 4 потока, 26 ГБ ОЗУ, $ 242,00
• Внутренние, длительные задачи — 2 сервера n1-highmem-4, 4 потока, 26 ГБ ОЗУ, $ 242,00
• Внутреннее кэширование (Redis) — 1 сервер n1-highmem-4, 4 потока, 26 ГБ ОЗУ, $ 121,00
• База данных — 6 серверов n1-standard-64, 64 потока, 240 ГБ оперативной памяти, $ 9320,64 + 1600 $ 4x1TB Disk
• Поиск — 1 сервер n1-highmem-4, 4 потока, 26 ГБ оперативной памяти, $ 121,00
• Серверная часть, сервисы изображений — 1 сервер n1-standard-16, 16 потоков, 60 ГБ ОЗУ, $ 388,36
• Хранение, резервное копирование базы данных, резервное копирование образов — 6 ТБ, $ 210
• Трафик — 12 ТБ, 1320 $

На момент написания этой статьи общая стоимость инфраструктуры составляла бы 16062,72 долл. США в месяц.

Здесь есть две интересные вещи.

1. Во-первых, хотя AWS и Azure были очень похожи, машины Google, похоже, получают больше вычислительной мощности и лучшую цену.
2. Тем не менее, основным условием сделки является их постоянное хранение, что очень дорого.

Digital Ocean
Digital Ocean появился чуть позже на вечеринке, но они точно разбили его. У них было два очень уникальных предложения.

• В отличие от AWS, который может быть громоздким и сложным в настройке, Digital Ocean и его капли (как они называют виртуальные машины) чрезвычайно просты в установке и запуске.
• Они также написали тонны действительно хороших статей о том, как запускать различные программные стеки и сервисы на своих машинах.
• Эти два преимущества велики, но самым большим было то, что каждая капля имела доступ к большому SSD.
• В то время, когда AWS поставлял относительно медленные и дорогие диски, DO начал предоставлять доступ к сверхбыстрым SSD по отличной цене.

Давайте посмотрим на инфраструктуру, которая отвечает требованиям и ее цене.

• Балансировщик нагрузки — 1 сервер, 8 потоков, 32 ГБ оперативной памяти, $ 160,00
• Изображения — 1 сервер, 24 потока, 128 ГБ ОЗУ, 640,00 долл. США + 400,00 долл. США, блочное хранилище 4 ТБ
• Front-end — 2 сервера, 8 потоков, 32 ГБ оперативной памяти, $ 320,00
• Внутренние, длительные задачи — 2 сервера, 8 потоков, 32 ГБ оперативной памяти, $ 320,00
• Внутреннее кэширование (Redis) — 1 сервер, 8 потоков, 32 ГБ ОЗУ, $ 160,00
• База данных — 12 серверов, 24 потока, 128 ГБ ОЗУ, 2,56 ТБ, $ 7680,00
• Поиск — 1 сервер, 8 потоков, 32 ГБ оперативной памяти, $ 160,00
• Серверная часть, сервисы изображений — 1 сервер, 16 потоков, 64 ГБ ОЗУ, $ 320
• Хранение, резервное копирование базы данных, резервное копирование образов — 6 ТБ, $ 120,00
• Трафик — 12 ТБ, без дополнительных сборов, входит в стоимость машины

На момент написания этой статьи общая стоимость инфраструктуры составила бы 10280 долларов в месяц.

• В Digital Ocean не так много больших машин, как мы хотели для базы данных, поэтому мы заменили каждую машину на две другие, вдвое меньшие по размеру, что приводит к тому же количеству ресурсов, но немного сложнее в управлении.
• Конечно, самое главное, что вы получаете гораздо лучшие цены, чем AWS, Google и Microsoft.
• В то же время вы получаете большое хранилище SSD, в то время как три других провайдера предоставляют очень мало хранилища по умолчанию, и в большинстве случаев это медленный тип.
• Тем не менее, это не только хранилище, но и большой объем трафика на машину, поэтому вам не нужно платить дополнительно, как вы платите за 3 крупнейших поставщика.
• Основным недостатком является то, что Digital Ocean не предоставляет много других услуг, которые вы можете найти у таких провайдеров, как AWS и Azure.
• Пока что Digital Ocean предлагает лучшее решение, экономя почти 6000 долларов по сравнению с Google. Можем ли мы сделать лучше?

Облако OVH

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

Давайте посмотрим на инфраструктуру, которая отвечает требованиям и ее цене.

• Балансировщик нагрузки — 1 сервер B2-30, 8 потоков, 30 ГБ ОЗУ, $ 102,00
• Изображения — 1 сервер R2-120, 8 потоков, 120 ГБ ОЗУ, 174,00 $ + 180,00 $ 4TB Disk
• Front-end — 2 B2-30 сервера, 8 потоков, 30 ГБ оперативной памяти, $ 204,00
• Внутренние, длительные задачи — 2 сервера B2-30, 8 потоков, 30 ГБ оперативной памяти, $ 204,00
• Внутреннее кэширование — 1 сервер B2-30, 8 потоков, 30 ГБ оперативной памяти, $ 102,00
• База данных — 6 серверов R2-240, 24 потока, 240 ГБ ОЗУ, 2,56 ТБ, $ 2052,00 и $ 270 дисков
• Поиск — 1 сервер B2-30, 8 потоков, 30 ГБ оперативной памяти, $ 102,00
• Бэк-энд, сервисы изображений — 1 сервер R2-60, 4 потока, 60 ГБ оперативной памяти, $ 86,39
• Хранение, резервное копирование базы данных, резервное копирование образов — 6 ТБ, $ 67,20
• Трафик — 12 ТБ, без дополнительных сборов, входит в стоимость машины

Общая стоимость инфраструктуры на момент написания этой статьи составила бы 3543,59 долларов в месяц.

• Да, эти цифры верны. Цена почти в 5 раз меньше, чем у Google, и в 3 раза меньше, чем у Digital Ocean!
• И это не просто цена. Их сетевой трафик не измеряется, поэтому вам не нужно тратить целое состояние на трафик, который вы получаете.
• Это какая-то афера? Это надежно?
• Это абсолютно реально. Мы строим сервисы и платформы, обслуживающие миллионы пользователей каждый месяц на OVH.
• Мы доверяем им так же, как доверяем AWS, Azure, Google или Digital Ocean.
• Клиент, о котором мы вам рассказали, использовал OVH для всего, что ему нужно, и это был отличный опыт.

Как и в случае с Digital Ocean, основным недостатком является отсутствие многих управляемых сервисов, таких как AWS, Azure и Google.

OVH Выделенный
Я уже говорил вам, что OVH является крупнейшим облачным провайдером в мире для выделенных серверов с минимальным набором ресурсов.

Вы получаете полную скорость диска, полный доступ к процессору и памяти, а также минимальную задержку.

Угадай, что? Эти серверы оценены очень хорошо.

Давайте посмотрим на инфраструктуру, которая отвечает требованиям и ее цене.

• Балансировщик нагрузки — 1 сервер EG-32, 8 потоков, оперативная память 32 ГБ, $ 119,00
• Обслуживание миллионов изображений — 1 сервер EG-128, 8 потоков, 120 ГБ ОЗУ, 4 ТБ, $ 269,00
• Front-end — 2 сервера EG-32, 8 потоков, 32 ГБ оперативной памяти, $ 238,00
• Внутренние, длительные задачи — 2 сервера EG-32, 8 потоков, 32 ГБ ОЗУ, $ 238,00
• Внутреннее кэширование — 1 сервер EG-32, 8 потоков, оперативная память 32 ГБ, $ 119,00
• База данных — 6 серверов EG-256-L, 24 потока, 240 ГБ ОЗУ, 4 ТБ диска, $ 2946,00
• Поиск — 1 сервер EG-32, 8 потоков, 32 ГБ оперативной памяти, $ 119,00
• Серверная часть, сервисы изображений — 1 сервер EG-64, 12 потоков, 64 ГБ ОЗУ, $ 185,99
• Хранение, резервное копирование базы данных, резервное копирование образов — 6 ТБ, $ 67,20
• Трафик — 12 ТБ, сборов нет, трафик не измеряется

На момент написания этой статьи общая стоимость инфраструктуры составила бы 4301,19 долларов в месяц.

• Это дороже, чем OVH Cloud, но производительность поразительна, и все еще намного дешевле, чем Google, Amazon, Microsoft и даже Digital Ocean.
• Тем не менее, я должен признать одну вещь. Выбранная инфраструктура рассчитана на виртуальные машины, а не на «голые железные» серверы.
• Когда виртуальная машина умирает, обычно вы можете запустить точную реплику в течение нескольких секунд, как будто ничего не произошло.
• Когда умирает специализированная машина из чистого металла, и если нет других машин, вам, возможно, придется подождать. Если есть, вы можете получить новую машину через несколько минут. Это немного, но в некоторых случаях может быть неприемлемо.
• Более того, это требует большей избыточности, поэтому реальной инфраструктуре потребуется еще несколько серверов, а общая стоимость может возрасти до 5000 долларов. Не так уж плохо.

Просто выбрав OVH Cloud вместо Google, вы сэкономите 150 000 долларов в год, а затем можете потратить их там, где это важно.

Вот почему наш клиент с вышеупомянутой платформой с большим успехом использует OVH на выделенных машинах и в облачных экземплярах.

• Я знаю, что AWS, Azure и Google — это место для многих предпринимателей и предприятий. Большинство людей просто так доверяют им, потому что они очень известные бренды.
• Тем не менее, мы много работали над OVH в течение нескольких лет, и их услуги были просто удивительными. Вы получаете отличное соотношение цены и качества.
• Мы используем AWS в течение многих лет. У нас также есть клиенты, работающие на своих платформах в Azure и Google. Однако я обнаружил несколько проблем, которые меня беспокоят.

1. Во-первых, как только вы начинаете расти, ваши расходы проходят через крышу. Зачастую самым большим сюрпризом для многих компаний является то, что они платят за трафик, входящий и исходящий между сетью AWS и Интернетом.
2. Во-вторых, предполагаемые преимущества управляемых сервисов (например, AWS RDS) не так уж велики.

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

Если вы хотите запустить бережливый стартап или улучшить итоги, OVH — отличное место для вас.

www.terlici.com/2018/12/18/build-for-just-small.html

• added 4*100G with a new path between Frankfurt and Warsaw
• upgraded DataIX_EU from 4*10G to 1*100G at Frankfurt
• upgraded the Transit with TeliaCarrier from 4*10G to 1*100G at PaloAlto
• added 100G of peering with BTGroup at London

• Added 100G of peering with tsystemsde at Frankfurt
• Upgraded Equinix IX from 4*10G to 1*100G at Dallas
• Upgraded our peering with Bell from 4*10G to 8*10G at Montreal
• Upgraded our peering with Telstra from 2*10G to 4*10G at London

Последние дни огромных миграций американских клиентов, которые пришли с последними годами приобретения VMware




и еще один колокейшн