Облачная платформа от MIRhosting – новости, примеры реализаций, обсуждение

Несмотря ни на что:)

Сотрудники компании помогли перекинуть 2 адреса.

Техническая поддержка для Trial - очень хороша) Впервые вижу, чтобы кто-то бесплатно переписал ревайты под nginx во время переноса.

Сотруднику Vyacheslav Большое спасибо :) До 4х часов ночи бодался с сайтами

Warses, спасибо за информацию. Как я понимаю, вопросы с производительностью были решены, они связаны не с платформой а с настройками приложений и скрипта (тикет 305397).

Для внешних доступов покупать IP не нужно, достаточно использовать endpoint. А между узлами есть внутренние IP.

Касательно балансера, в новой версии платформы, которая ожидается для установки где-то через 2-3 недели, будет анонсирован новый балансер, который позволит настраивать такие вещи более подробно. На данный момент, можно выбирать между nginx, varnish, haproxy, и дальше уже их настраивать и тюнинговать самостоятельно при необходимости.

Будем рады помочь в дальнейшем.

И снова мы хотим поднять тему настоящего облака.

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

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

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

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

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

При масштабировании серверов в рамках облачного окружения, пользователи автоматически получают максимальную доступность своих приложений и серверов. Это реализуется с помощью функции последовательного рестарта и разворачивания. Данный подход позволяет осуществлять различные операции, такие как повторный запуск контейнера, разворачивание приложения, обновление Docker контейнера и изменение количества клаудлет без сервисного простоя. В версии облачной платформы 4.9, этот механизм был реализован с помощью добавления специальной опции задержки. Это позволило устанавливать конкретные временные рамки (30 секунд, по умолчанию) между запущенными операциями контейнеров одного слоя, выделяя им дополнительное время для восстановления полной работоспособности.

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

Регистрируйтесь на нашем облаке, все плюшки мы даем абсолютно бесплатно в течении 14 дней - https://mirhosting.com/ru/cloud. :)

Уточняем, при чем тут я и какая то статья? :)

1, 2 не имею ничего общего с этим

Не пугайте, плавали, ploop ничего не мeняет, это же имидж или раздел на удаленном хранилище на общей файловой системе. Ploop я использовал лет пять тому назад с OpenVZ, подключал дополнительно виртуалкам раздел под MySQL внутри виртуалки. Не оправдался, лучще simfs на том же SSD. Если уж говорить о производительности, то надо говорить или о прямом подключении LVM или iSCSI или о ещё какой то хитрой системе. И самое главное, о канале между вычислительным центром и хранилищем, тут слабое место.

Скажем тут наши мнения расходятся на 180 градусов, не думаю что стоит ввязыватся в спор. Цена/качество для клиента лучше будет на стороне моего понятия. Удобство для хозяйна, да на Вашей стороне.

50 Ghz суммируя потоки? Сами понимаете, что 50 Ghz тут даже не пахнет, даже при одном клиенте на всём облаке. Прикинем сколько будет клиентов, которые все будет шарить эти потоки ;) Я противник суммировать частоту процессора, это технически неграмотно. Если аппликация может использовать несколько потоков, то все потоки будут обрабатываться на частоте ядра, с тем приоритетом, который выставлен для контейнера, только в несколько потоков. Если аппликация не способна работать с несколькими потоками, то частота будет та же, только всего один поток. И эти другие vCPU просто будет простаивать. Это же сами понимаете, но всё равно занимаетесь маркетингом ;)

Также повторюсь, что не имею никакого отношения к каким то статьям, также почти всё своё время работы в этой области предлагал OpenVZ + один из Xen/Vmware/KVM. Virtuozzo тоже только уважаю, но не вижу смысла использовать, не нравится мне платные имитации виртуализации. Если для каких то проектов пойти на платную платформу, то только на базе Citrixx или Vmware.

LineHost, я правда даже не знаю что Вам и сказать. :) Все Ваши аргументы - это выражение личного опыта, привычек, веры = субъективны, причем сферически. Облако Вы наше не пробовали.

Рассуждаете о том что мол это не будет работать так как мы пишем, как будто мы пишем не о рабочем production решении с 1000+ клиентами, в том числе несколько крупных enterprise из разных стран, а каким-то девелоперскими идеями на уровне становления задач.

И 50 Ghz клиенты берут, есть такие, которым как раз нужны CPU и потоки. И скорости стораджа превышающие характеристики SSD дисков, при этом с 3 реалтайм копиями на разные датацентры, и все остальное.

Это не какие-то идеи, это рабочее решение, находящееся в коммерческом виде более года, со стремительно растущей клиентской базой. Не надо писать что это не будет работать. Это работает. Сделано по уму, и как раз таки нацелено на удобство пользователей. И да, открыть классический VPS с фиксированными ресурсами у нас тоже можно, просто поставив 2 ползунка (максимальные доступные ресурсы и резервируемые ресурсы) на одно значение. Просто решение дает гораздо больше, чем только это.

LineHost, Я Вас очень уважаю, как одного из старожил и грамотного технического специалиста. И я прекрасно понимаю, что у Вас сложились свои собственные взгляды и убеждения за все годы, как и что должно быть. Давайте Вы как минимум попробуете наше решение? Прежде всего не как пользователь, а как хостер. А я напомню, что у нас есть White Label Partner программа, в том числе и на Вашем собственном оборудовании. И будем говорить не о том, какие виртуализации лучше, а о том что можно делать на этом мощном решении. Это гораздо более интересный разговор.

MIRhosting.com, Не превышает скорость ваших VPS DO или Лизвеб новые облачные в обычном виде, ненужно выдумывать.

Очень жду пока OVH выкатит VPS на NVME рейдах, вот там будет прямо супер скорость:)

Ничего личного, просто опыт.

На дефолтном сторадж тиере - нет, не превышает. На скоростном - превышает.

Напоминаю:

Tier I: disk throughput - up to 250 Mb/s; iops – up to 200 o/s; 0.0001 euro per Gb, 10 Gb of disk space for free

Tier II: disk throughput - up to 400 Mb/s; iops - up to 20 000 o/s; 0.0003 euro per Gb, no free usage

В отличие от OVH и прочих других, мы даем гарантированные цифры, а не просто магическое слово SSD или NVMe

Пример на контейнере на Tier II:

CT-11952-bash-4.1# fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test \

> --bs=4k --iodepth=64 --size=4G --readwrite=randwrite

test: (g=0): rw=randwrite, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=64

fio-2.0.13

Starting 1 process

test: Laying out IO file(s) (1 file(s) / 4096MB)

^Cbs: 1 (f=1): [w] [19.4% done] [0K/97564K/0K /s] [0 /24.4K/0 iops] [eta 00m:29s]

fio: terminating on signal 2

test: (groupid=0, jobs=1): err= 0: pid=667: Fri Nov 11 13:39:58 2016

write: io=825888KB, bw=113384KB/s, iops=28345 , runt= 7284msec

cpu : usr=2.92%, sys=30.94%, ctx=115118, majf=0, minf=19

IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0%

submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%

complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%

issued : total=r=0/w=206472/d=0, short=r=0/w=0/d=0

Run status group 0 (all jobs):

WRITE: io=825888KB, aggrb=113383KB/s, minb=113383KB/s, maxb=113383KB/s, mint=7284msec, maxt=7284msec

Поделитесь цифрами от DO и Leaseweb?

MIRhosting.com, Я мерил в период пользования облаков, в тч и ваших, сейчас всё скинул в 1 дедик с ssd.

Через недели 2-3, возьму вновь ради Вас в LW и DO и выложу сюда.

Андрей, скажу честно - за всю свою практику я не столкнулся с ситуацией, чтобы не хватило моих обычных впсок 😕 С мощных серверов снимал разные проекты, и они продолжали у меня стабильно работать на моих VPS. Просто есть ошибки, которые делают многие вебмастеры, и эти ошибки обязательно надо устранить. Наверно 90% ресурсов, для которых вебмастеры арендуют мощные сервера, может работать на виртуалке с 2-4 GB RAM. Я даже тарифов не делаю по мощнее, так как они реально ненужны. Но обещаю, если столкнусь, когда мне будет недостаточно мощности одного сервера, я обязательно попробую ваш вариант. Вы наверно просто направляете свои услуги на другой сегмент, я нацелен на монстров.

Что касается тестов, не знаю как LW и как на сегодняшний день в OVH, но у меня на впсках с SSD результат зависит от ноды... Но по моему быстрее чем на локальном подсоединении диск, ни одно удаленное хранилище работать не может....

На VPS с одной ноды:

[root@gama /]# date

Fri Nov 11 17:53:20 EET 2016

[root@gama tmp]# fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=4G --readwrite=randwrite

test: (g=0): rw=randwrite, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=64

fio-2.2.8

Starting 1 process

Jobs: 1 (f=1): [w(1)] [100.0% done] [0KB/503.3MB/0KB /s] [0/129K/0 iops] [eta 00m:00s]

test: (groupid=0, jobs=1): err= 0: pid=21717: Fri Nov 11 17:47:59 2016

write: io=4096.0MB, bw=399458KB/s, iops=99864, runt= 10500msec

cpu : usr=10.12%, sys=81.84%, ctx=5277, majf=1, minf=24

IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0%

submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%

complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%

issued : total=r=0/w=1048576/d=0, short=r=0/w=0/d=0, drop=r=0/w=0/d=0

latency : target=0, window=0, percentile=100.00%, depth=64

Run status group 0 (all jobs):

WRITE: io=4096.0MB, aggrb=399457KB/s, minb=399457KB/s, maxb=399457KB/s, mint=10500msec, maxt=10500msec

И на root@sigma:/tmp# date

Pn Lap 11 17:54:55 EET 2016

root@sigma:/tmp# fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=4G --readwrite=randwrite

test: (g=0): rw=randwrite, bs=4K-4K/4K-4K, ioengine=libaio, iodepth=64

2.0.8

Starting 1 process

Jobs: 1 (f=1): [w] [100.0% done] [0K/267.1M /s] [0 /68.6K iops] [eta 00m:00s]

test: (groupid=0, jobs=1): err= 0: pid=29252

write: io=4096.0MB, bw=267545KB/s, iops=66886 , runt= 15677msec

cpu : usr=5.28%, sys=43.22%, ctx=3407, majf=0, minf=17

IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0%

submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%

complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%

issued : total=r=0/w=1048576/d=0, short=r=0/w=0/d=0

Run status group 0 (all jobs):

WRITE: io=4096.0MB, aggrb=267545KB/s, minb=267545KB/s, maxb=267545KB/s, mint=15677msec, maxt=15677msec

И на VPS на ноде с меньшей нагрузкой:

root@sigma:/tmp# date

Pn Lap 11 17:54:55 EET 2016

root@sigma:/tmp# fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=4G --readwrite=randwrite

test: (g=0): rw=randwrite, bs=4K-4K/4K-4K, ioengine=libaio, iodepth=64

2.0.8

Starting 1 process

Jobs: 1 (f=1): [w] [100.0% done] [0K/267.1M /s] [0 /68.6K iops] [eta 00m:00s]

test: (groupid=0, jobs=1): err= 0: pid=29252

write: io=4096.0MB, bw=267545KB/s, iops=66886 , runt= 15677msec

cpu : usr=5.28%, sys=43.22%, ctx=3407, majf=0, minf=17

IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0%

submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%

complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%

issued : total=r=0/w=1048576/d=0, short=r=0/w=0/d=0

Run status group 0 (all jobs):

WRITE: io=4096.0MB, aggrb=267545KB/s, minb=267545KB/s, maxb=267545KB/s, mint=15677msec, maxt=15677msec

Обе ноды уже укомплективанны... Чтоб не было разных мыслей, прилагаю картинку.

Если у меня будет больше клиентов на PRO уровне услуг, я могу обеспечить этот параметр примерно на 50% лучше.

Ниже результат с KVM виртуалки, которая сама по себе уже во время тестирования имела load avg ~1.86

[root@serv tmp]# fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=4G --readwrite=randwrite

test: (g=0): rw=randwrite, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=64

fio-2.0.13

Starting 1 process

test: Laying out IO file(s) (1 file(s) / 4096MB)

Jobs: 1 (f=1): [w] [100.0% done] [0K/154.8M/0K /s] [0 /39.7K/0 iops] [eta 00m:00s]

test: (groupid=0, jobs=1): err= 0: pid=23908: Fri Nov 11 18:59:49 2016

write: io=4096.0MB, bw=179866KB/s, iops=44966 , runt= 23319msec

cpu : usr=13.94%, sys=59.07%, ctx=24611, majf=1, minf=18

IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0%

submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%

complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%

issued : total=r=0/w=1048576/d=0, short=r=0/w=0/d=0

Run status group 0 (all jobs):

WRITE: io=4096.0MB, aggrb=179866KB/s, minb=179866KB/s, maxb=179866KB/s, mint=23319msec, maxt=23319msec

Disk stats (read/write):

vda: ios=998/1043131, merge=11/401, ticks=4493/749421, in_queue=753773, util=100.00%

LineHost, это стандартные цифры одного локального SSD диска без нагрузки.

Как я уже и сказал, мы можем совершенно спокойно дать цифры превышающие эти цифры, используя SDS. То что я показывал выше - это стандартные значения 2 разных уровней стораджа, они приблизительно ориентированы на типовые значения от амазон https://aws.amazon.com/ebs/details/

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

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

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

На досуге, посмотрите на рост Amazon, Azure и некоторых других, подумайте, что не так с этими компаниями, которые туда мигрируют. И это при том, что многие плюются что на одних что на других. Подумайте, что не так с нашими клиентами облаков, что мы уже вышли практически на скорость добавления по 1 стойки в 1-2 месяца. И это вобщем практически без рекламы вообще. Правда, мне Вам доказывать что черное это черное ну как бы утомляет. Разговор из разряда - зачем мне ваш паровоз, у меня есть лошадь и меня все устраивает :)