11.02.2019 00:35
onlinehead 70 11700 Источник
Давеча на глаза мне тут попалось аж две статьи из одного корпоративного блога, касающиеся облаков — одна про Kubernetes, а во второй была попытка замера производительности по методике, которая мне показалась сомнительной (спойлер — и не зря).

Про K8s мне тоже есть что сказать, но поговорим про производительность.

Недоверие к результатам было вызвано многими факторами, но основными из них для меня стали следующие: параметров запуска тестов не было, количество итераций не озвучено, как выбирались машины не озвучено, подробной конфигурации тоже не было. Сомнительно, в общем.
В целом, я пользуюсь в основном Google Cloud и AWS (в сумме уже с десяток лет опыта по ним набежало) и с отечественными облачными провайдерам особо не работаю, но, по стечению обстоятельств, у меня есть активные аккаунты в Selectel, MCS, Я.Облаке и, после этого теста, еще и в Azure.

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

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

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

Интересующихся прошу под кат.

Методика


Виртуальные машины


У каждого облачного провайдера последовательно запускаются в разных зонах доступности (если зоны две, то 1 машина первой зоне и 2 во второй) три виртуальные машины с 4 CPU, 8 GB оперативной памяти и системным диском на 50 GB.

Тип процессора/инстанса — новейший из доступных, если есть выбор.

Тип ВМ — shared с полным выделением ядер.

Тип дисков — сетевой SSD с возможностью перемонтирования на другую ВМ.

Опции гарантированного выделения IOPS или машины оптимизированные под это не использовались, если это не предусмотрено стандартными условиями использования и отказаться от этого нельзя.

Файловая система дефолтная — ext4.

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

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

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

Операционная система — Ubuntu 16.04 последнего доступного уровня патчей.

Расчет стоимости


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

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

Для AWS это Spot инстансы, для GCE — Preemptible инстансы. При подходящей архитектуре приложения ими вполне можно успешно пользоваться без вреда для него, но с пользой для кошелька, проверено как лично мной, так и десятками компаний, использующих и то, и другое.
К этой же категории можно отнести тип диска в Selectel. Несмотря на то, что в основных замерах участвовали диски типа «Быстрый», существует еще ощутимо более дешевый «Универсальный», не блистающий скоростью, но подходящий для огромного количества задач. Варианты с его использованием тоже были учтены при окончательных расчетах.

Тесты


Для запуска тестов был написан вот такой скриптик, из которого видно все параметры запуска:

Скрипт тестирования
#!/usr/bin/env bash
TIME=60

# Workload 70% read 30% write
cat > fio-rand.fio << EOL
[global]
name=fio-rand-RW
filename=fio-rand-RW
rw=randrw
rwmixread=70
rwmixwrite=30
bs=4K
direct=1
numjobs=1
time_based=1
runtime=${TIME}

[file1]
size=2G
iodepth=16
EOL

echo "Run FIO"
for i in {1..3}; do
  echo "$i iter:"
  fio fio-rand.fio |grep -E "(read|write|bw|iops|READ|WRITE)" |grep -v "Disk"
done
echo "Run stress-ng."
for i in {1,2,4}; do
  for z in {1..3}; do
    echo -n "$z iter. Stress-NG for $i CPU: "
    stress-ng --cpu $i --cpu-method matrixprod --metrics-brief -t $TIME  2>&1 |sed -n '6p'| awk '{print $5}'
  done
done
for i in {1,2,4}; do
  for z in {1..3}; do
    echo -n "$z iter. Sysbench CPU for $i thread(s): "
    sysbench --num-threads=$i --max-time=$TIME --test=cpu run 2>&1|grep "total time:"|awk '{print $3}'
  done
done
for i in {1,2,4}; do
  for z in {1..3}; do
    echo -n "$z iter. Sysbench Memory for $i thread(s): "
    sysbench --num-threads=$i --max-time=$TIME --test=memory run 2>&1| grep "Operations performed:"
  done
done


Для всех тестов, кроме Sysbench CPU, больше — лучше.

Результаты всех запусков были собраны в Excel таблицы для дальнейший расчетов.
Ну, вроде как делал — рассказал, теперь надо рассказать что получилось.

Тестирование


Машинка-пример вне теста.


Облака принято сравнивать с обычными железными серверами. Я не вижу в этом особого смысла, так как облако — это не только и не столько непосредственно вычислительные мощности, а в первую очередь — экосистема но, тем не менее, я думаю многим все-таки будет интересно такое сравнение. Ну и вообще, с чем то надо сравнивать. С чем то близким, известным и понятным.
Именно железной машинки под рукой у меня не оказалось, зато есть весьма не новая рабочая станция Dell, она же домашний сервер с известным процессором (E5-4650L @ 2.60GHz), подходящим количеством не самой быстрой памяти DDR3 EEC (если быть откровенным — самой медленной из тех, что вообще были совместимы) и SSD диском SmartBuy, купленным года 4 назад и недавно переехавшим в состав этой сборки.

Так как работает все это под FreeBSD 11.2, то средствами bhyve была создана подходящая виртуалочка и там же был запущен тест.

Лог запуска
Run FIO
1 iter:
  read : io=891652KB, bw=14861KB/s, iops=3715, runt= 60001msec
    bw (KB  /s): min=  116, max=17520, per=100.00%, avg=15449.34, stdev=2990.83
  write: io=381908KB, bw=6365.3KB/s, iops=1591, runt= 60001msec
    bw (KB  /s): min=   49, max= 7752, per=100.00%, avg=6620.06, stdev=1290.46
   READ: io=891652KB, aggrb=14860KB/s, minb=14860KB/s, maxb=14860KB/s, mint=60001msec, maxt=60001msec
  WRITE: io=381908KB, aggrb=6365KB/s, minb=6365KB/s, maxb=6365KB/s, mint=60001msec, maxt=60001msec
2 iter:
  read : io=930228KB, bw=15504KB/s, iops=3875, runt= 60001msec
    bw (KB  /s): min= 5088, max=17144, per=99.98%, avg=15500.61, stdev=2175.23
  write: io=398256KB, bw=6637.6KB/s, iops=1659, runt= 60001msec
    bw (KB  /s): min= 2064, max= 7504, per=100.00%, avg=6639.82, stdev=979.69
   READ: io=930228KB, aggrb=15503KB/s, minb=15503KB/s, maxb=15503KB/s, mint=60001msec, maxt=60001msec
  WRITE: io=398256KB, aggrb=6637KB/s, minb=6637KB/s, maxb=6637KB/s, mint=60001msec, maxt=60001msec
3 iter:
  read : io=886780KB, bw=14779KB/s, iops=3694, runt= 60001msec
    bw (KB  /s): min= 1823, max=17248, per=100.00%, avg=15520.09, stdev=2453.59
  write: io=379988KB, bw=6333.3KB/s, iops=1583, runt= 60001msec
    bw (KB  /s): min=  731, max= 7488, per=100.00%, avg=6647.33, stdev=1054.67
   READ: io=886780KB, aggrb=14779KB/s, minb=14779KB/s, maxb=14779KB/s, mint=60001msec, maxt=60001msec
  WRITE: io=379988KB, aggrb=6333KB/s, minb=6333KB/s, maxb=6333KB/s, mint=60001msec, maxt=60001msec
Run stress-ng.
1 iter. Stress-NG for 1 CPU: 12227
2 iter. Stress-NG for 1 CPU: 12399
3 iter. Stress-NG for 1 CPU: 12134
1 iter. Stress-NG for 2 CPU: 23812
2 iter. Stress-NG for 2 CPU: 23558
3 iter. Stress-NG for 2 CPU: 21254
1 iter. Stress-NG for 4 CPU: 39495
2 iter. Stress-NG for 4 CPU: 39876
3 iter. Stress-NG for 4 CPU: 42370
1 iter. Sysbench CPU for 1 thread(s): 11.0566s
2 iter. Sysbench CPU for 1 thread(s): 11.0479s
3 iter. Sysbench CPU for 1 thread(s): 11.0451s
1 iter. Sysbench CPU for 2 thread(s): 5.6159s
2 iter. Sysbench CPU for 2 thread(s): 5.5664s
3 iter. Sysbench CPU for 2 thread(s): 5.5407s
1 iter. Sysbench CPU for 4 thread(s): 2.8368s
2 iter. Sysbench CPU for 4 thread(s): 2.8801s
3 iter. Sysbench CPU for 4 thread(s): 2.8244s
1 iter. Sysbench Memory for 1 thread(s): Operations performed: 104857600 (2537704.01 ops/sec)
2 iter. Sysbench Memory for 1 thread(s): Operations performed: 104857600 (2536025.17 ops/sec)
3 iter. Sysbench Memory for 1 thread(s): Operations performed: 104857600 (2472121.34 ops/sec)
1 iter. Sysbench Memory for 2 thread(s): Operations performed: 104857600 (3182800.43 ops/sec)
2 iter. Sysbench Memory for 2 thread(s): Operations performed: 104857600 (3379413.65 ops/sec)
3 iter. Sysbench Memory for 2 thread(s): Operations performed: 104857600 (3306495.59 ops/sec)
1 iter. Sysbench Memory for 4 thread(s): Operations performed: 104857600 (4300089.71 ops/sec)
2 iter. Sysbench Memory for 4 thread(s): Operations performed: 104857600 (4163689.93 ops/sec)
3 iter. Sysbench Memory for 4 thread(s): Operations performed: 104857600 (4163996.47 ops/sec)


Если перевести результаты в табличный вид, получается следующее:
Test Iter 1 Iter 2 Iter 3 Average StDev
FIO READ IOPS 3715.00 3875.00 3694.00 3761.33 99.00
FIO WRITE IOPS 1591.00 1659.00 1583.00 1611.00 41.76
STRESS-NG 1 CPU 12227.00 12399.00 12134.00 12253.33 134.45
STRESS-NG 2 CPU 23812.00 23558.00 21254.00 22874.67 1409.27
STRESS-NG 4 CPU 39495.00 39876.00 42370.00 40580.33 1561.56
Sysbench CPU for 1 11.06 11.05 11.05 11.05 0.01
Sysbench CPU for 2 5.62 5.57 5.54 5.57 0.04
Sysbench CPU for 4 2.84 2.88 2.82 2.85 0.03
Sysbench Mem t 1 2537704.01 2536025.17 2472121.34 2515283.51 37388.96
Sysbench Mem t 2 3182800.43 3379413.65 3306495.59 3289569.89 99393.41
Sysbench Mem t 4 4300089.71 4163689.93 4163996.47 4209258.70 78662.11

Ну, опорные данные есть, теперь непосредственно результаты тестирования провайдеров.

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

Яндекс.Облако


Результаты по зоне ru-central1-a:

Таблица результатов
Test Iter 1 Iter 2 Iter 3 Average StDev
FIO READ IOPS 554.00 543.00 545.00 547.33 5.86
FIO WRITE IOPS 237.00 232.00 233.00 234.00 2.65
STRESS-NG 1 CPU 10236.00 10045.00 10161.00 10147.33 96.23
STRESS-NG 2 CPU 19756.00 19479.00 20291.00 19842.00 412.77
STRESS-NG 4 CPU 18743.00 17906.00 18192.00 18280.33 425.43
Sysbench CPU for 1 11.94 11.95 11.98 11.96 0.02
Sysbench CPU for 2 7.19 7.23 6.16 6.86 0.61
Sysbench CPU for 4 3.72 3.72 3.70 3.71 0.01
Sysbench Mem t 1 2080442.66 2085059.55 2079872.00 2081791.40 2844.64
Sysbench Mem t 2 2460594.62 2715142.01 2536824.57 2570853.73 130641.04
Sysbench Mem t 4 2978385.59 2928369.70 3020014.59 2975589.96 45886.36


Результаты по зоне ru-central1-b:

Таблица результатов
Test Iter 1 Iter 2 Iter 3 Average StDev
FIO READ IOPS 543.00 537.00 523.00 534.33 10.26
FIO WRITE IOPS 232.00 230.00 224.00 228.67 4.16
STRESS-NG 1 CPU 10634.00 10848.00 11870.00 11117.33 660.55
STRESS-NG 2 CPU 22109.00 20861.00 21020.00 21330.00 679.30
STRESS-NG 4 CPU 18964.00 19449.00 18992.00 19135.00 272.29
Sysbench CPU for 1 11.30 11.35 11.34 11.33 0.03
Sysbench CPU for 2 5.87 5.88 5.89 5.88 0.01
Sysbench CPU for 4 3.56 3.55 3.54 3.55 0.01
Sysbench Mem t 1 2190808.15 2197111.57 2197600.12 2195173.28 3788.20
Sysbench Mem t 2 2442631.19 2433028.20 2415710.66 2430456.68 13643.25
Sysbench Mem t 4 3010239.12 3168720.68 3088677.50 3089212.43 79242.13


Результаты по зоне ru-central1-c:

Таблица результатов
Test Iter 1 Iter 2 Iter 3 Average StDev
FIO READ IOPS 541.00 551.00 558.00 550.00 8.54
FIO WRITE IOPS 232.00 236.00 239.00 235.67 3.51
STRESS-NG 1 CPU 10424.00 10192.00 10325.00 10313.67 116.41
STRESS-NG 2 CPU 19637.00 20330.00 19585.00 19850.67 415.93
STRESS-NG 4 CPU 28884.00 28477.00 28750.00 28703.67 207.42
Sysbench CPU for 1 11.67 11.64 11.68 11.67 0.02
Sysbench CPU for 2 6.02 6.05 7.06 6.38 0.59
Sysbench CPU for 4 3.40 3.40 3.40 3.40 0.00
Sysbench Mem t 1 2131168.41 2130201.75 2142809.68 2134726.61 7016.81
Sysbench Mem t 2 2777100.50 2592860.27 2226863.89 2532274.89 280076.82
Sysbench Mem t 4 2834838.09 2935298.85 2753443.73 2841193.56 91093.99


Сводные результаты:
Test Average Avg Min Avg Max StDev StDev %
FIO READ IOPS 543.89 534.33 550.00 8.38 1.5%
FIO WRITE IOPS 232.78 228.67 235.67 3.66 1.6%
STRESS-NG 1 CPU 10526.11 10147.33 11117.33 518.72 4.9%
STRESS-NG 2 CPU 20340.89 19842.00 21330.00 856.61 4.2%
STRESS-NG 4 CPU 22039.67 18280.33 28703.67 5786.99 26.3%
Sysbench CPU for 1 11.65 11.33 11.96 0.31 2.7%
Sysbench CPU for 2 6.37 5.88 6.86 0.49 7.7%
Sysbench CPU for 4 3.55 3.40 3.71 0.16 4.5%
Sysbench Mem t 1 2137230.43 2081791.40 2195173.28 56732.39 2.7%
Sysbench Mem t 2 2511195.10 2430456.68 2570853.73 72533.45 2.9%
Sysbench Mem t 4 2968665.32 2841193.56 3089212.43 124154.35 4.2%

Хочу обратить отдельное внимание на один примечательный факт.

При полной нагрузке всех ядер виртуальных машин в зонах A и B суммарная производительность НИЖЕ, чем при нагрузке только двух ядер из четырех.

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

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

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

Mail.RU Cloud (MCS)


У Mail.ru только две зоны доступности, поэтому два теста были проведены на разных машинах в одной зоне.

Результаты по зоне «Москва-Восток»(первая ВМ):

Таблица с результатами
Test Iter 1 Iter 2 Iter 3 Average StDev
FIO READ IOPS 487.00 538.00 534.00 519.67 28.36
FIO WRITE IOPS 209.00 231.00 229.00 223.00 12.17
STRESS-NG 1 CPU 7359.00 6567.00 7022.00 6982.67 397.46
STRESS-NG 2 CPU 14144.00 14916.00 13137.00 14065.67 892.08
STRESS-NG 4 CPU 21381.00 21199.00 21032.00 21204.00 174.55
Sysbench CPU for 1 15.54 16.20 14.98 15.57 0.61
Sysbench CPU for 2 7.30 7.70 7.53 7.51 0.20
Sysbench CPU for 4 4.02 4.09 3.79 3.96 0.16
Sysbench Mem t 1 1117493.99 1161261.85 1423941.92 1234232.59 165744.17
Sysbench Mem t 2 1819474.62 1692128.17 1668347.81 1726650.20 81262.88
Sysbench Mem t 4 2357943.97 2379492.56 2312976.14 2350137.56 33938.38


Результаты по зоне «Москва-Восток»(вторая ВМ):

Результаты тестирования
Test Iter 1 Iter 2 Iter 3 Average StDev
FIO READ IOPS 475.00 509.00 472.00 485.33 20.55
FIO WRITE IOPS 205.00 218.00 204.00 209.00 7.81
STRESS-NG 1 CPU 6953.00 7030.00 7127.00 7036.67 87.19
STRESS-NG 2 CPU 14623.00 13945.00 13523.00 14030.33 554.94
STRESS-NG 4 CPU 27022.00 27184.00 27670.00 27292.00 337.23
Sysbench CPU for 1 14.88 13.44 14.45 14.26 0.74
Sysbench CPU for 2 6.89 7.13 6.69 6.90 0.22
Sysbench CPU for 4 3.52 3.49 3.68 3.57 0.10
Sysbench Mem t 1 1129165.42 1238462.80 1344025.16 1237217.79 107435.28
Sysbench Mem t 2 1904396.37 1740914.98 1733216.87 1792842.74 96684.92
Sysbench Mem t 4 2416702.17 2437844.98 2384159.80 2412902.32 27043.55


Результаты по зоне «Москва-Север»:

Результаты тестирования
Test Iter 1 Iter 2 Iter 3 Average StDev
FIO READ IOPS 510.00 647.00 613.00 590.00 71.34
FIO WRITE IOPS 218.00 277.00 262.00 252.33 30.66
STRESS-NG 1 CPU 9657.00 9742.00 9867.00 9755.33 105.63
STRESS-NG 2 CPU 19251.00 20069.00 19677.00 19665.67 409.12
STRESS-NG 4 CPU 39020.00 38665.00 38461.00 38715.33 282.88
Sysbench CPU for 1 12.45 12.53 12.66 12.55 0.11
Sysbench CPU for 2 6.25 6.20 6.22 6.22 0.02
Sysbench CPU for 4 3.18 3.16 3.16 3.17 0.01
Sysbench Mem t 1 2003899.51 1990350.38 1974380.86 1989543.58 14775.85
Sysbench Mem t 2 1990419.20 2022621.53 1934822.52 1982621.08 44415.93
Sysbench Mem t 4 2337084.52 2227633.06 2021779.21 2195498.93 160090.01


Сводные результаты:

Test Average Avg Min Avg Max StDev StDev %
FIO READ IOPS 531.67 485.33 590.00 53.36 10.0%
FIO WRITE IOPS 228.11 209.00 252.33 22.11 9.7%
STRESS-NG 1 CPU 7924.89 6982.67 9755.33 1585.44 20.0%
STRESS-NG 2 CPU 15920.56 14030.33 19665.67 3243.41 20.4%
STRESS-NG 4 CPU 29070.44 21204.00 38715.33 8890.10 30.6%
Sysbench CPU for 1 14.13 12.55 15.57 1.52 10.7%
Sysbench CPU for 2 6.88 6.22 7.51 0.64 9.3%
Sysbench CPU for 4 3.57 3.17 3.96 0.40 11.2%
Sysbench Mem t 1 1486997.99 1234232.59 1989543.58 435219.81 29.3%
Sysbench Mem t 2 1834038.01 1726650.20 1982621.08 132864.82 7.2%
Sysbench Mem t 4 2319512.93 2195498.93 2412902.32 111890.39 4.8%

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

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

Selectel


Результаты его тестирования получились очень интересными. В абсолюте он предоставляет самые мощные 4-х ядерные машины из всех протестированных провайдеров.

Результаты по зоне «Москва — Берзарина-1»:

Результаты тестирования
Test Iter 1 Iter 2 Iter 3 Average StDev
FIO READ IOPS 2319.00 2294.00 2312.00 2308.33 12.90
FIO WRITE IOPS 998.00 986.00 995.00 993.00 6.24
STRESS-NG 1 CPU 11320.00 11038.00 10936.00 11098.00 198.91
STRESS-NG 2 CPU 23164.00 22093.00 22558.00 22605.00 537.04
STRESS-NG 4 CPU 43879.00 44118.00 44086.00 44027.67 129.74
Sysbench CPU for 1 12.01 11.96 11.97 11.98 0.02
Sysbench CPU for 2 6.01 5.99 5.99 6.00 0.02
Sysbench CPU for 4 3.01 3.00 3.00 3.00 0.01
Sysbench Mem t 1 2158876.40 2162098.22 2158738.03 2159904.22 1901.32
Sysbench Mem t 2 2413547.34 2340801.67 2569554.40 2441301.14 116874.54
Sysbench Mem t 4 2858920.38 2935705.54 2714476.62 2836367.51 112325.57


Результаты по зоне «Москва — Берзарина-2»:

Таблица с результатами
Test Iter 1 Iter 2 Iter 3 Average StDev
FIO READ IOPS 1735.00 1729.00 1724.00 1729.33 5.51
FIO WRITE IOPS 745.00 742.00 740.00 742.33 2.52
STRESS-NG 1 CPU 18231.00 18462.00 18518.00 18403.67 152.13
STRESS-NG 2 CPU 36965.00 36495.00 37006.00 36822.00 283.93
STRESS-NG 4 CPU 74272.00 74428.00 74218.00 74306.00 109.05
Sysbench CPU for 1 11.22 11.17 11.15 11.18 0.03
Sysbench CPU for 2 5.60 5.60 5.60 5.60 0.00
Sysbench CPU for 4 2.83 2.81 2.81 2.82 0.01
Sysbench Mem t 1 2396762.92 2405750.19 2394240.05 2398917.72 6050.06
Sysbench Mem t 2 1980511.45 2079328.96 1968664.26 2009501.56 60761.74
Sysbench Mem t 4 2283159.05 2271698.71 2299665.98 2284841.25 14059.32


Результаты по зоне «СПБ — Дубровка-1»:

Таблица с результатами
Test Iter 1 Iter 2 Iter 3 Average StDev
FIO READ IOPS 2550.00 2618.00 2666.00 2611.33 58.29
FIO WRITE IOPS 1096.00 1126.00 1147.00 1123.00 25.63
STRESS-NG 1 CPU 10801.00 10512.00 11175.00 10829.33 332.41
STRESS-NG 2 CPU 21418.00 21642.00 23179.00 22079.67 958.62
STRESS-NG 4 CPU 44183.00 44557.00 43012.00 43917.33 806.03
Sysbench CPU for 1 11.97 11.99 11.99 11.99 0.01
Sysbench CPU for 2 5.99 5.99 6.00 5.99 0.01
Sysbench CPU for 4 3.02 3.00 3.00 3.01 0.01
Sysbench Mem t 1 2159958.70 2162062.66 2158540.58 2160187.31 1772.13
Sysbench Mem t 2 2430650.73 2512678.85 2417945.57 2453758.38 51420.53
Sysbench Mem t 4 3171660.68 3018827.14 3343661.47 3178049.76 162511.39


Сводная таблица с результатами:
Test Average Avg Min Avg Max StDev StDev %
FIO READ IOPS 2216.33 1729.33 2611.33 448.14 20.2%
FIO WRITE IOPS 952.78 742.33 1123.00 193.49 20.3%
STRESS-NG 1 CPU 13443.67 10829.33 18403.67 4297.59 32.0%
STRESS-NG 2 CPU 27168.89 22079.67 36822.00 8363.96 30.8%
STRESS-NG 4 CPU 54083.67 43917.33 74306.00 17513.14 32.4%
Sysbench CPU for 1 11.72 11.18 11.99 0.46 4.0%
Sysbench CPU for 2 5.86 5.60 6.00 0.23 3.9%
Sysbench CPU for 4 2.94 2.82 3.01 0.11 3.7%
Sysbench Mem t 1 2239669.75 2159904.22 2398917.72 137912.86 6.2%
Sysbench Mem t 2 2301520.36 2009501.56 2453758.38 252972.39 11.0%
Sysbench Mem t 4 2766419.51 2284841.25 3178049.76 450693.81 16.3%

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

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

Получается эдакая лотерея, правда с учетом что даже если не повезет, все равно все будет весьма и весьма прилично.

Google Cloud


Результаты тестирования GCE особых сюрпризов не принесли.

Все вполне предсказуемо, гомогенно и в целом соответствует заявленному.

Результаты по зоне europe-west1-b:

Результаты тестирования
Test Iter 1 Iter 2 Iter 3 Average StDev
FIO READ IOPS 924.00 910.00 888.00 907.33 18.15
FIO WRITE IOPS 396.00 391.00 380.00 389.00 8.19
STRESS-NG 1 CPU 14237.00 14137.00 14094.00 14156.00 73.37
STRESS-NG 2 CPU 28576.00 28419.00 28544.00 28513.00 82.96
STRESS-NG 4 CPU 29996.00 29880.00 29449.00 29775.00 288.22
Sysbench CPU for 1 12.63 12.66 12.67 12.65 0.02
Sysbench CPU for 2 6.52 6.41 6.38 6.44 0.08
Sysbench CPU for 4 3.35 3.56 3.56 3.49 0.12
Sysbench Mem t 1 2055240.49 2056617.63 2054720.94 2055526.35 980.13
Sysbench Mem t 2 1377683.73 1346931.63 1397680.79 1374098.72 25563.81
Sysbench Mem t 4 2279937.89 2275427.56 2278615.94 2277993.80 2318.63


Результаты по зоне europe-west-1c:

Результаты тестирования
FIO READ IOPS 946.00 995.00 984.00 975.00 25.71
FIO WRITE IOPS 406.00 428.00 422.00 418.67 11.37
STRESS-NG 1 CPU 14256.00 14250.00 14423.00 14309.67 98.20
STRESS-NG 2 CPU 28875.00 29057.00 29256.00 29062.67 190.56
STRESS-NG 4 CPU 30317.00 30462.00 29478.00 30085.67 531.23
Sysbench CPU for 1 12.52 12.49 12.61 12.54 0.06
Sysbench CPU for 2 6.28 6.30 6.31 6.29 0.02
Sysbench CPU for 4 3.38 3.57 3.52 3.49 0.10
Sysbench Mem t 1 2085832.84 2066794.24 2086303.39 2079643.49 11130.26
Sysbench Mem t 2 1368168.11 1535725.51 1710618.59 1538170.74 171238.33
Sysbench Mem t 4 2375534.54 2307610.22 2386046.89 2356397.22 42576.47


Результаты по зоне europe-west1-d:

Результаты тестирования
Test Iter 1 Iter 2 Iter 3 Average StDev
FIO READ IOPS 885.00 910.00 943.00 912.67 29.09
FIO WRITE IOPS 379.00 390.00 405.00 391.33 13.05
STRESS-NG 1 CPU 14254.00 14230.00 14008.00 14164.00 135.63
STRESS-NG 2 CPU 28262.00 28321.00 28473.00 28352.00 108.86
STRESS-NG 4 CPU 29615.00 29312.00 29138.00 29355.00 241.39
Sysbench CPU for 1 12.61 12.65 12.66 12.64 0.03
Sysbench CPU for 2 6.37 6.35 6.35 6.36 0.01
Sysbench CPU for 4 3.43 3.56 3.55 3.52 0.07
Sysbench Mem t 1 2050031.60 2068677.64 2052707.70 2057138.98 10081.96
Sysbench Mem t 2 1228313.90 1530374.73 1345581.79 1368090.14 152283.14
Sysbench Mem t 4 2335035.15 2420871.72 2361505.39 2372470.75 43956.33


Сводная таблица с результатами:
Test Average Avg Min Avg Max StDev StDev %
FIO READ IOPS 931.67 907.33 975.00 37.62 4.0%
FIO WRITE IOPS 399.67 389.00 418.67 16.50 4.1%
STRESS-NG 1 CPU 14209.89 14156.00 14309.67 86.50 0.6%
STRESS-NG 2 CPU 28642.56 28352.00 29062.67 372.63 1.3%
STRESS-NG 4 CPU 29738.56 29355.00 30085.67 366.69 1.2%
Sysbench CPU for 1 12.61 12.54 12.65 0.06 0.5%
Sysbench CPU for 2 6.36 6.29 6.44 0.07 1.1%
Sysbench CPU for 4 3.50 3.49 3.52 0.01 0.4%
Sysbench Mem t 1 2064102.94 2055526.35 2079643.49 13482.64 0.7%
Sysbench Mem t 2 1426786.53 1368090.14 1538170.74 96508.32 6.8%
Sysbench Mem t 4 2335620.59 2277993.80 2372470.75 50549.23 2.2%

Тут даже комментировать особо нечего.

Производительность в 4 потока едва отличается от двух, но не деградирует.

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

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

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

AWS


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

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

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

Результаты по зоне eu-central-1a:

Результаты тестирования
Test Iter 1 Iter 2 Iter 3 Average StDev
FIO READ IOPS 1839.00 1976.00 2083.00 1966.00 122.31
FIO WRITE IOPS 789.00 850.00 895.00 844.67 53.20
STRESS-NG 1 CPU 21422.00 21722.00 21736.00 21626.67 177.38
STRESS-NG 2 CPU 43305.00 43331.00 43197.00 43277.67 71.06
STRESS-NG 4 CPU 40876.00 40884.00 40888.00 40882.67 6.11
Sysbench CPU for 1 8.77 8.77 8.77 8.77 0.00
Sysbench CPU for 2 4.40 4.40 4.40 4.40 0.00
Sysbench CPU for 4 2.52 2.52 2.52 2.52 0.00
Sysbench Mem t 1 3063495.18 3064238.67 3063452.11 3063728.65 442.21
Sysbench Mem t 2 1848705.16 1841708.24 1751938.22 1814117.21 53962.11
Sysbench Mem t 4 2413033.89 2249609.19 2299986.20 2320876.43 83691.15


Результаты по зоне eu-central-1b:

Результаты тестирования
Test Iter 1 Iter 2 Iter 3 Average StDev
FIO READ IOPS 1723.00 1988.00 2101.00 1937.33 194.03
FIO WRITE IOPS 739.00 855.00 903.00 832.33 84.32
STRESS-NG 1 CPU 21785.00 21733.00 21741.00 21753.00 28.00
STRESS-NG 2 CPU 43370.00 43323.00 40351.00 42348.00 1729.61
STRESS-NG 4 CPU 40857.00 40864.00 40916.00 40879.00 32.23
Sysbench CPU for 1 8.77 8.77 8.77 8.77 0.00
Sysbench CPU for 2 4.39 4.40 4.39 4.39 0.00
Sysbench CPU for 4 2.52 2.52 2.52 2.52 0.00
Sysbench Mem t 1 3065227.23 3065688.95 3063830.23 3064915.47 967.78
Sysbench Mem t 2 2032840.35 1987864.46 1968489.39 1996398.07 33013.31
Sysbench Mem t 4 2684716.32 2654257.87 2618592.53 2652522.24 33096.05


Результаты по зоне eu-central-1c:

Результаты тестирования
Test Iter 1 Iter 2 Iter 3 Average StDev
FIO READ IOPS 1761.00 2003.00 2108.00 1957.33 177.95
FIO WRITE IOPS 756.00 861.00 906.00 841.00 76.97
STRESS-NG 1 CPU 21632.00 21708.00 21615.00 21651.67 49.52
STRESS-NG 2 CPU 43247.00 43236.00 43283.00 43255.33 24.58
STRESS-NG 4 CPU 39931.00 39359.00 40835.00 40041.67 744.20
Sysbench CPU for 1 8.77 8.77 8.77 8.77 0.00
Sysbench CPU for 2 4.40 4.40 4.40 4.40 0.00
Sysbench CPU for 4 2.52 2.52 2.52 2.52 0.00
Sysbench Mem t 1 3064343.66 3064434.20 2998820.16 3042532.67 37856.17
Sysbench Mem t 2 2235882.60 2088501.51 2166875.91 2163753.34 73740.15
Sysbench Mem t 4 2870035.79 2813221.50 2771999.66 2818418.98 49224.29


Сводная таблица результатов:
Test Average Avg Min Avg Max StDev StDev %
FIO READ IOPS 1953.56 1937.33 1966.00 14.70 0.8%
FIO WRITE IOPS 839.33 832.33 844.67 6.33 0.8%
STRESS-NG 1 CPU 21677.11 21626.67 21753.00 66.90 0.3%
STRESS-NG 2 CPU 42960.33 42348.00 43277.67 530.41 1.2%
STRESS-NG 4 CPU 40601.11 40041.67 40882.67 484.50 1.2%
Sysbench CPU for 1 8.77 8.77 8.77 0.00 0.0%
Sysbench CPU for 2 4.40 4.39 4.40 0.00 0.1%
Sysbench CPU for 4 2.52 2.52 2.52 0.00 0.1%
Sysbench Mem t 1 3057058.93 3042532.67 3064915.47 12594.10 0.4%
Sysbench Mem t 2 1991422.87 1814117.21 2163753.34 174871.16 8.8%
Sysbench Mem t 4 2597272.55 2320876.43 2818418.98 253330.90 9.8%

Как я уже сказал выше — результаты меня удивили.

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

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

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

Так же, гомогенность результатов просто отличная, все предсказуемо и без сюрпризов.

Azure


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

Сразу хочу объяснить, что регион был выбран из принципа «где-то в Европе», а тип машины — на 100% подходящий под условия (4 процессора, 8Гб памяти).
В первой итерации теста это был A4 v2, отмеченный как «General purpose», с которым была опубликована эта статья. Пришедшие в комменты знатоки объяснили мне что я сделал не так и что оказывается у Azure машина, которая медленнее, может стоить дороже той, которая быстрее и без чтения документации или гугления об этом не узнаешь. После чего результаты были обновлены на базе типа F4s

Результаты по зоне France-Central-1:

Результаты тестирования
Test Iter 1 Iter 2 Iter 3 Awerage StDev
FIO READ IOPS 1066.00 1102.00 1038.00 1068.67 32.08
FIO WRITE IOPS 457.00 473.00 445.00 458.33 14.05
STRESS-NG 1 CPU 9470.00 10059.00 10759.00 10096.00 645.30
STRESS-NG 2 CPU 20424.00 20502.00 20940.00 20622.00 278.14
STRESS-NG 4 CPU 39039.00 39294.00 39141.00 39158.00 128.35
Sysbench CPU for 1 10.32 10.42 10.50 10.42 0.09
Sysbench CPU for 2 5.35 5.35 5.33 5.35 0.01
Sysbench CPU for 4 2.77 2.78 2.76 2.77 0.01
Sysbench Mem t 1 2449793.14 2467589.35 2456056.19 2457812.89 9027.22
Sysbench Mem t 2 2370286.78 2388077.81 2299377.92 2352580.84 46925.93
Sysbench Mem t 4 2697042.08 2625447.20 2707918.64 2676802.64 44806.37


Результаты по зоне France-Central-2:

Результаты тестирования
Test Iter 1 Iter 2 Iter 3 Awerage StDev
FIO READ IOPS 1037.00 1104.00 1102.00 1081.00 38.12
FIO WRITE IOPS 445.00 473.00 473.00 463.67 16.17
STRESS-NG 1 CPU 10159.00 10360.00 10452.00 10323.67 149.84
STRESS-NG 2 CPU 21027.00 20025.00 20415.00 20489.00 505.08
STRESS-NG 4 CPU 39530.00 40927.00 40170.00 40209.00 699.32
Sysbench CPU for 1 10.39 9.95 9.91 10.08 0.27
Sysbench CPU for 2 5.09 5.13 5.19 5.14 0.05
Sysbench CPU for 4 2.69 2.75 2.66 2.70 0.04
Sysbench Mem t 1 2568336.75 2450640.64 2567906.16 2528961.18 67827.92
Sysbench Mem t 2 2401273.88 2362027.64 2372950.76 2378750.76 20255.79
Sysbench Mem t 4 2740927.62 2787787.19 2770497.39 2766404.07 23696.44


Результаты по зоне France-Central-3:

Результаты тестирования
Test Iter 1 Iter 2 Iter 3 Awerage StDev
FIO READ IOPS 1436.00 830.00 1136.00 1134.00 303.00
FIO WRITE IOPS 614.00 355.00 487.00 485.33 129.51
STRESS-NG 1 CPU 10834.00 10326.00 10763.00 10641.00 275.10
STRESS-NG 2 CPU 21505.00 21108.00 21428.00 21347.00 210.53
STRESS-NG 4 CPU 42194.00 41540.00 41427.00 41720.33 414.08
Sysbench CPU for 1 9.87 9.75 9.79 9.80 0.06
Sysbench CPU for 2 5.04 5.05 5.13 5.08 0.05
Sysbench CPU for 4 2.67 2.65 2.67 2.66 0.01
Sysbench Mem t 1 2622263.24 2616326.80 2632668.25 2623752.76 8271.93
Sysbench Mem t 2 2495841.62 2438685.04 2556294.51 2496940.39 58812.43
Sysbench Mem t 4 2814306.59 2783117.34 2846909.91 2814777.95 31898.90


Сводная таблица результатов:
Test Average Avg Min Avg Max StDev StDev %
FIO READ IOPS 1094.56 1068.67 1134.00 34.71 3.2%
FIO WRITE IOPS 469.11 458.33 485.33 14.30 3.0%
STRESS-NG 1 CPU 10353.56 10096.00 10641.00 273.73 2.6%
STRESS-NG 2 CPU 20819.33 20489.00 21347.00 461.79 2.2%
STRESS-NG 4 CPU 40362.44 39158.00 41720.33 1288.04 3.2%
Sysbench CPU for 1 10.10 9.80 10.42 0.31 3.0%
Sysbench CPU for 2 5.19 5.08 5.35 0.14 2.7%
Sysbench CPU for 4 2.71 2.66 2.77 0.05 2.0%
Sysbench Mem t 1 2536842.28 2457812.89 2623752.76 83250.19 3.3%
Sysbench Mem t 2 2409424.00 2352580.84 2496940.39 76912.65 3.2%
Sysbench Mem t 4 2752661.55 2676802.64 2814777.95 70006.71 2.5%

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

Итоги


Производительность


Начнем со сводной таблицы результатов.

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


Чем свелтее, тем лучше

Посмотрим подробнее на производительность CPU:



В целом, лидерство по средней измеренной производительности для одно- и двух-ядерной нагрузки прочно удерживает AWS. На втором месте Google Cloud.

Из российских провайдеров лучше всего себя показал Selectel. Кроме третьего места по неполной нагрузке у него однозначное первое при нагрузке всех ядер, даже с учетом неравномерности результатов между зонами (что неприятно, но в данном случае не влияет).

Теперь память:



По скорости работы с памятью плашку памяти пальму первенства удерживает AWS для однопоточного режима, для двух-поточного — Azure и Я.Облако для четырех-поточного.

Диски:



По скорости дисков у нас однозначный победитель — Selectel. Ничего подобного за сопоставимые деньги никто из участников сравнения не предлагает.

На втором месте — AWS благодаря разрешенному Burst-у и в целом приличной скорости.
За ним GCE и Azure, а замыкают список Я.Облако и MSC, которые предлагают примерно одинаковые по производительности решения.

Стоимость относительно производительности


А теперь поговорим о еще одном интересном факторе — стоимости.

Это сравнение не в коем случае не покрывает совокупности стоимости решений на разных платформах, его цель проста — сопоставить стоимость единицы производительности у разных провайдеров.

За основу расчета возьмем тест stress-ng.
Расчетные цены за 1 месяц использования каждого инстанса (без НДС):
Provider Yandex.Cloud MCS Selectel GCE AWS Azure
Price (cur) 3799.12 3608 4050.624 103.08 147.57 147.46
Price (rub) 3799.12 3608 4050.624 6747.6168 9659.9322 9652.7316
Alt price (cur) 3799.12 3608 3,454.94 35.6 56.07 9652.7316
Alt price (rub) 3799.12 3608 3,454.94 2330.376 3670.3422 9652.7316

Таблица стоимости требует некоторого пояснения.

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

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

Так же, из-за разницы валют, стоимость AWS, Azure (да, я знаю что он умеет показывать в рублях (как-то), их калькулятор показал мне значения в долларах) и GCE приведена к рублевому эквиваленту, соответствующему курсу 65.46 рублей за доллар США.

Так же, для Azure у меня не получилось выделить стоимость диска, стандартный диск инстанса там 16 Гб, сколько будет действительно стоить диск из калькулятора не очень понятно (там еще и количество запросов учитывается), так что цена указана только за непосредственно инстанс, хотя общей ситуации это все равно не меняет, Azure остается самым дорогим.

Итак, стоимость каждого решения, приведенная к рублям за попугай в тесте stress-ng за минимальное количество ресурсов, которые было получено в тесте:


Меньше — лучше

Если посчитать на основании средних результатов теста, картина принципиально не поменяется, но кое что-что все таки изменится:


Меньше — лучше

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

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

Альтернативная стоимость с учетом экономии за счет сценария использования, приведенная к рублям за попугай в тесте stress-ng за минимальное количество ресурсов, которые было получено в тесте:


Меньше — лучше

Оно же, но к среднему количеству ресурсов:



Здесь картина меняется.

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

В случае тяжелой нагрузки конкуренцию им составляет Selectel, предлагающий ресурсы практически за те же деньги, но с меньшим количеством «уступков» (все же, его ноды постоянны и не выключаются в произвольным момент времени, в отличии от AWS Spot и Google Preemptible инстансов).

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

Вместо выводов


Тест получился длинный, но как по мне — интересный.

Для себя я сделал некоторые выводы по результатам, надеюсь он поможет и вам посмотреть на вопрос производительности облачных платформ немного с другой стороны и возможно немного облегчит муки выбора, а так же поможет в диагностике проблем производительности на некоторых платформах из-за выявленных «особенностей».
**UPDATE** Обновлены выводы и цены Selectel, т.к. в них бы некорректно учтен НДС
**UPDATE2** Обновлены результаты Azure на новый тип нод, обновлены выводы, но принципиально все равно ничего не поменялось

Комментарии (70)


  1. Andrew_Pinkerton
    11.02.2019 05:30
    #19739994
    +2

    Довольно интересные результаты.
    Если у вас есть возможность, то хотелось бы увидеть в результатах Hetzner Clolud
    и Digital Ocean


    1. onlinehead Автор
      11.02.2019 14:24
      #19741902

      DO точно могу, Hetzner — надо в них посмотреть, но наверное тоже больших проблем быть не должно.


      1. mOlind
        11.02.2019 15:18
        #19742182

        Добавлю в список хотелок UpCloud и Vultr


        1. onlinehead Автор
          11.02.2019 17:20
          #19742938
          -1

          Vultr выглядит очень вкусно с точки зрения цен, правда он не совсем «облако», так как кроме серверов ничего не предоставляет, как я вижу, что не совсем вписыватеся в условия теста.


          1. mOlind
            11.02.2019 17:33
            #19742996

            Чего это они не облако? Облачные сервера есть, облачное хранилище есть. Тем более что тест из статьи меряет только железки.


          1. mvs
            11.02.2019 18:50
            #19743382

            У Vultr'а очень странные сетевые затыки (1-2 раза в день пропадает связь на 1-2 секунды), из-за этого ухожу с них.


          1. QuakeMan
            13.02.2019 01:17
            #19749446

            Еще бы хотелка — scaleway


  1. TiesP
    11.02.2019 07:37
    #19740094

    Спасибо, интересно. А на машинах с использованием GPU вы не работали в облаках? Было бы интересно узнать, даже субъективное, мнение о цене/производительности.


    1. onlinehead Автор
      11.02.2019 15:21
      #19742208

      Если интересует именно GPU, то там никаких чудес, производительность та же, как если бы вы использовали заявленную карту локально (за вычетом производительности самой машины в тех вопросах, что не касаются GPU расчетов). У AWS/GCE в документации подробно написано что за карты используются, а тесты их легко гуглятся.


  1. gecube
    11.02.2019 07:46
    #19740104

    Отличное сравнение, спасибо!
    По неточностям — написал в личку.


    1. onlinehead Автор
      11.02.2019 15:17
      #19742178

      Базы как сервис интересны в первую очередь другим — отсутствием затрат на обслуживание, пусть даже путем некоторой переплаты.
      Для того же ClickHouse сейчас такой сервис предлагает только Yandex, так что сравнивать такое не очень корректно. Да и не у всех впринципе есть сервис баз.


  1. Hardened
    11.02.2019 08:20
    #19740166
    +1

    Содержательно.


    По выводам — так как диск сетевой и заказывается отдельно, то было бы корректнее вытащить его стоимость из цены инстанса и дать сравнение IOPS на рубль. Причём добавить туда, как минимум, "Быстрые" от Selectel, в сравнении с универсальным.


    У российских провайдеров, в отличие от зарубежных, тарифы на проц не защиты в инстанса и отдельно указаны. Таблица price performance по ним тоже была бы интересна


    1. onlinehead Автор
      11.02.2019 14:03
      #19741792

      Да и у иностранных не указаны, на самом деле.
      Цель сравнения была понять именно стоимость небольшой машинки в комплекте, а 50Гб диск и так самая минималка. Пересчитать без его стоимости могу конечно, но это совсем однобоко получится.
      Но в любом случае, спасибо за предложение.


  1. SychevIgor
    11.02.2019 08:38
    #19740208

    Предлагаю экспертам по соотвествующим облакам собраться в комментариях, дать правильные ссылки, чтобы провести методологически корректное сравнение (чтобы в научную статью было можно податься)
    Судя по дисклеймер по Azure, эту часть вообще лучше выкинуть т.к. сам дисклеймер можно сократить да — выбрал что-то, где-то, получил какой-то результат, потом понял что все сложнее, но все равно напишу, какой azure плохой.

    Ссылки по Azure docs.microsoft.com/en-us/azure/virtual-machines/linux/acu нормирование производительности разных типов ядер к ядру типа a1. Я бы взял какие-нибудь D4_v3 или F4s_v2 для этого теста. При этом, они будет на 30% дешевле a4_v2

    1 A4m v2 (4 vCPU(s), 32 GB RAM) x 744 Hours; Linux – Ubuntu; Pay as you go; 0 managed OS disks – E4 $216.50
    1 D4 v3 (4 vCPU(s), 16 GB RAM) x 744 Hours; Linux – Ubuntu; Pay as you go; 0 managed OS disks – S4 $159.22
    1 F4s v2 (4 vCPU(s), 8 GB RAM) x 744 Hours; Linux – Ubuntu; Pay as you go; 0 managed OS disks – S4 $142.85


    1. SychevIgor
      11.02.2019 08:42
      #19740218

      Заодно предлагаю все таки в North Europe взять т.к. там на 7-20% дешевле, чем в Central France (стоимость ресрсов в разных регионах отличаются именно по этому — взял где-то в Европе- звучит крайне не серьезным подходом)

      France Central 1 A4m v2 (4 vCPU(s), 32 GB RAM) x 744 Hours; Linux – Ubuntu; Pay as you go; 0 managed OS disks – E4 $278.26
      France Central 1 D4 v3 (4 vCPU(s), 16 GB RAM) x 744 Hours; Linux – Ubuntu; Pay as you go; 0 managed OS disks – S4 $166.66
      France Central 1 F4s v2 (4 vCPU(s), 8 GB RAM) x 744 Hours; Linux – Ubuntu; Pay as you go; 0 managed OS disks – S4 $150.29


      1. SychevIgor
        11.02.2019 09:35
        #19740394

        Кстати, размер и типы дисков не были указаны. Какие использовались для Azure (можно названием вроде P4, можно типом и размером на пример- standard ssd 32 gb)?
        Тестировали на OSDisk или DataDisks — это тоже может влиять.

        Дело в том, что от размера диска и его типа зависят и его параметры по performance (iops/Throughput) Тут можно сэкономить пару баксов и проиграть в 2 раза по параметрам.

        docs.microsoft.com/en-us/azure/virtual-machines/linux/disks-standard-ssd#scalability-and-performance-targets

        По поводу курса $ и ценах в рублях — если мы говорим про portal.azure.com там показывается цена в той валюте, в которой у Вас подписка. Т.е. если подписка рублевая, то и цены будет рублевые. Если про azure.microsoft.com/en-us/pricing/calculator то внизу страницы есть язык и валюта (такой вот UX)


        1. onlinehead Автор
          11.02.2019 14:20
          #19741888

          Давайте я вам в одном сообщении отвечу.

          (такой вот UX)

          Честно говоря я бы сказал это обо всем интерфейсе Azure. Мне всегда казалось, что AWS накрутил у себя излишне сложно, пока вот его не увидел.
          Дело в том, что от размера диска и его типа зависят и его параметры по performance (iops/Throughput)

          У AWS тоже. Диск был 32 Гб, потому что он не умеет выдавать произвольный размер, в отличие от всех участников, условие было — диск на 50Гб, ну я и оставил дефолтный. Можно было бы на 64 наверное, но к производительности диска (в целом), претензий то больших нет.
          стоимость ресрсов в разных регионах отличаются именно по этому — взял где-то в Европе- звучит крайне не серьезным подходом

          Если бы я шел путем оптимизиции стоимости в целом, я бы взял машины на AWS и GCE в Штатах, они там самые дешевые, но тем не менее я взял материковую Европу, так как у всех остальных сервера там же.
          Что касается типов машин. Из всех предложенных вами 4 ядрами и именно 8 Гб памяти обладает только F4s v2 которая, теоретически, в 2 раза быстрее.
          Это явно не поменяет финансовую картину, но давайте так.
          У вас я так понимаю есть подходящая компетенция — предложите мне вариант машины, в которой ровно 4 ядра и ровно 8 гб памяти с диском на 50Гб (ну или пусть будет 64) в Европе на материке, я его померю и добавлю в эту (сделаю апдейт) или следующую статью (если наберется материала). Идет?


          1. SychevIgor
            11.02.2019 21:34
            #19744112

            Со строго 8RAM не так много.
            Эту таблицу можно найти, когда создаете машину нажимаете размер и сверху фильтры указать.
            Azure диски умеет выдавать разного размера, просто это в UI не вынесено для диска с OS. Вопросы почему- даже MS вряд ли ответит.
            Но можно сделать следующий хак- дойти до последнего шага визарда, нажать download template и в него, руками задать в virtualMachines — properties — storageProfile -osDisk свойство «diskSizeGB»: «integer» docs.microsoft.com/en-us/azure/templates/microsoft.compute/2018-04-01/virtualmachines#template-format
            Согласен, не тривиальный шаг, но вот так работает портал.


            1. dikkini
              11.02.2019 23:38
              #19744490

              Да так работает практически вся продукция Микрософта, от Блокнота до Azure — ласково так, не тривиально.


  1. Temmokan
    11.02.2019 08:58
    #19740258
    +1

    В том же AWS EC2 достаточно много параметров (там и выделение квот на vCPU, сам тип CPU, резервированный или выданный «по количеству» параметр IOPS для дисков, и т.д.) — делать некий усреднённый анализ на примере одного только типа машины, думаю, даст «среднюю температуру по клинике, с учётом морга».

    Ну с ходу: если «general SSD» том вдвое большего размера, то количество доступных IOPS станет вдвое больше. Диски там относительно дёшевы, и наращиванием тома можно неплохо улучшить итоги тестирования.

    Итоги статистически интересные, но на практике — в общем случае — мало применимы.


    1. onlinehead Автор
      11.02.2019 14:07
      #19741814
      -1

      >В том же AWS EC2 достаточно много параметров

      Именно. А у других они отсутствуют. Ровно по этой причине я тестировал машинки «по-умолчанию», без каких либо оптимизаций и фич (стоящих отдельных денег), которые к тому же есть у одних, но нет у других.
      Но, к слову, если докинуть в тестовую машинку выделение процессора, утроить размер диска и изменить его тип на io1, то стоимость машины прилично уедет вперед и станет совсем неконкурента на фоне остальных, тогда ценовое сравнение потеряет смысл.


      1. Temmokan
        11.02.2019 16:32
        #19742628
        -1

        Тогда надо хотя бы указать, что одним только наращиванием диска можно ту же дисковую производительность поднять, а если использовать reserved instance, то и цены на треть упадут, с ходу.

        Я к тому, что надо такие особенности платформы явно указывать, в них-то весь цимес и есть. «По умолчанию» — это та самая средняя температура по клинике. Никто не берёт в AWS по умолчанию, кроме новичков, которым надо всё вначале потрогать и погонять.

        (это к тому, что не обзор плохой, а к тому то, что без подобных описаний платформ он существенно менее информативный)


        1. onlinehead Автор
          11.02.2019 16:56
          #19742780

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

          В условиях теста четко указан размер диска.
          Из AWS можно выжать очень неплохую производительность диска, но это за рамками обзора.
          а если использовать reserved instance, то и цены на треть упадут, с ходу.

          И это уже не on-demand, а у нас сравнение условий по on-demand нодам.
          Так-то почти любой вендор может еще и персональные условия дать при определенных обстоятельствах, причем достаточно вкусные, но это не повод ориентироваться на них.
          На счет AWS по-умолчанию — тут очень размытое понятие. Reserved вот тоже много кто не берет по определенным причинам (непостоянная нагрузка, неуверенность в типе нод, быстроменяющиеся обстоятельства), так что pay as you go вполне корректное сравнение, дальше идет набор уловок, чтобы замкнуть кастомера на себя.


  1. zolti
    11.02.2019 10:15
    #19740598
    +2

    Про Azure, выше, хорошо подметили. С вашей стороны, как автора, весьма непрофессионально, так поверхностно и тем самым неуважительно, включать это облако в тестирование без должной проработки существующих тарифов на VM. Выглядит как: «я сам не работал, не разобрался что к чему, включу в тест для общей кучи, ну заодно и на контрасте нормально так сыграю».


    1. gecube
      11.02.2019 13:42
      #19741686
      -1

      Если это рассматривать как стартовую точку и пищу для размышлений, то ОК. Главное, что автор не пытается выдавать черное за белое и честно признается, что глубоко вопрос Azure не копал.


    1. onlinehead Автор
      11.02.2019 14:23
      #19741900

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


      1. masyan
        11.02.2019 15:30
        #19742270

        «Если человек просто придет выбирать облако» — накликать виртуалок != облако

        «и если кому-то надо быть архитектором по этому облаку чтобы просто выбрать подходящую машинку» — когда тот же яндекс обрастёт таким же количеством сервисов, как эжар, я думаю, что у них тоже появится «ya.cloud certified кто-то там», вопрос времени.

        Не самая свежая картинка по эжару, но…
        image


        1. onlinehead Автор
          11.02.2019 17:04
          #19742830
          +1

          Как правило, переезд в облако начинается именно с перетаскивания какой-то текущей нагрузки с параллельным перепиливанием ее под особенности платформы. Но, конечно, всякое бывает.
          Но вообще, достаточно много проектов при мне начинались с «нам нужны виртуалки, объектный сторадж, базы и балансер», что в целом есть практически у всех (у большой тройки точно есть) и самое дорогое в этом наборе, не считая трафика (который вполне может встать дороже, чем все остально вместе взятое) — это виртуалки.
          Набор сервисов как минимум большой тройки весьма схож и все умеют практически все, что можно представить, плюс — со своими уникальными сервисами.
          Я кстати в статье специально сделал ремарку по поводу того, что речь идет исключительно о «накликать виртуалок в облаке и посмотреть насколько они быстрые», а не о выборе платформы как таковой с учетом всех ее особенностей.
          Ну и, еще раз, если даже подходящую виртуалку выбрать настолько неочевидно, то это не признак того, что все настолько круто, что архитект нужен, а того, что все настолько мутно, что архитект нужен.
          На смотря на всю крутость трех больших платформ в плане количества сервисов (а AWS как бы не побольше Azure будет), на двух из них по крайней мере невозможно купить машину дороже, но слабже, натыкиывая ее в интерфейсе.


  1. WW3
    11.02.2019 11:12
    #19740848

    Хотел бы заметить, что у селектела площадки в Москве расположены не на Березина, а на Берзарина и Авиамоторной.


    1. onlinehead Автор
      11.02.2019 17:04
      #19742834

      Fixed.


  1. stekov27
    11.02.2019 12:29
    #19741206

    Мне показалось или у «Azure Solution Architect» включился маркетинг своего болота?)
    Если уж говорить про локации, диски, и процы — то логичней упомянуть о всех «облачных провайдерах».


    1. SychevIgor
      11.02.2019 21:20
      #19744056

      В моем первом сообщении было написано:
      «Предлагаю экспертам по соотвествующим облакам собраться в комментариях, дать правильные ссылки, чтобы провести методологически корректное сравнение (чтобы в научную статью было можно податься)»
      Т.к. я не эксперт в google/aws, то написал только про явные вопросы к azure.

      Но так да, платят в MS построчно за рекламу


  1. rinaty
    11.02.2019 15:39
    #19742316

    У меня есть vultr могу дать для тестов, если нужен.


    Было бы очень интересно скорость сети/интернета еще как-то проверить. Говорят что у амазона плохо с этим. У меня например как-то получалось, что до серверов в той же зоне амазона (правда они за cloudflare) скорость с машине с aws была хуже чем из гугла (но я б не сказать что целенаправленно исследовал этот вопрос)


    1. onlinehead Автор
      11.02.2019 17:08
      #19742852

      (правда они за cloudflare)

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


      1. rinaty
        12.02.2019 00:10
        #19744578

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


  1. olegfil
    11.02.2019 16:09
    #19742496

    вторая ссылка на запрос «Azure виртуальные машины» выдает:
    «Серия A
    Экономичные виртуальные машины начального уровня для разработки и тестирования
    Виртуальные машины серии A обладают характеристиками производительности процессора и памяти, которые лучше всего подходят для рабочих нагрузок начального уровня, например для разработки и тестирования. Они экономичны и обеспечивают недорогой вариант использования Azure на начальном уровне. Av2 Standard — это новейшее поколение виртуальных машин серии А с такой же производительностью ЦП, но большим объемом ОЗУ на виртуальный ЦП и более высокой скоростью дисков.

    Среди вариантов использования — серверы разработки и тестирования, веб-серверы с низким уровнем трафика, базы данных малого и среднего размера, серверы для экспериментальных решений и репозитории код»

    При этом по первой ссылке серии A даже нет — там сразу предлагают серию начиная с B.

    То есть Вы просто на «отбейся» провели тест второго по величине в мире облачного провайдера и написали далеко идущие выводы якобы опираясь на то что «обычный» человек будет делать так-же как Вы (то есть не пользоваться поиском в интернете)?
    Очень глубокий и точный тест.
    PS: На экзамене на Azure Architect про серии ВМ фактически нет вопросов — там и без них хватает чего спросить. Просто потому что вся инфа по ВМ гуглится за 1 минуту.
    PPS: Всем Azure Architect корпорация зла Microsoft платит за позитивные комментарии — вот сейчас написал и пойду отоваривать!!! Переходите к нам — у нас печеньки :)


    1. gecube
      11.02.2019 16:21
      #19742572

      второго по величине в мире облачного провайдера

      второго ли? По мне так первые два — Amazon и Google.
      PPS: Всем Azure Architect корпорация зла Microsoft платит за позитивные комментарии — вот сейчас написал и пойду отоваривать!!! Переходите к нам — у нас печеньки :)

      «отличный» юмор.


      1. olegfil
        11.02.2019 16:28
        #19742612

        Ну вот статистика с Вами не соглашается:

        41% у AWS, 29 — Azure и всего 3 у Google

        www.skyhighnetworks.com/cloud-security-blog/microsoft-azure-closes-iaas-adoption-gap-with-amazon-aws

        www.zdnet.com/article/top-cloud-providers-2018-how-aws-microsoft-google-ibm-oracle-alibaba-stack-up

        B вот гартнеровский квандрант
        www.bmc.com/blogs/gartner-magic-quadrant-cloud-iaas

        Причем это в IaaS. В PaaS и SaaS у Microsoft еще лучше позиции.


    1. onlinehead Автор
      11.02.2019 17:11
      #19742870
      +1

      написали далеко идущие выводы якобы опираясь на то что «обычный» человек будет делать так-же как Вы (то есть не пользоваться поиском в интернете)?

      Вы italic написание в статье специально игнорируете?:)
      У меня к вам такой вопрос, раз все просто — почему из интерфейса вообще можно купить машину дороже, но слабже и при этом она первая в списке?
      А так, я там уже выше писал — озвучивайте материковый регион в Европе, тип инстанса с 4CPU/8Гб памяти (именно столько, не больше, не меньше) и я сделаю перетест. Мне не сложно, я за справедливость.


      1. olegfil
        11.02.2019 17:32
        #19742994

        Нет именно такой конфигурации, есть 4CPU и 16 Gb и 2и8.
        Что-бы выбрать A инстанс надо еще и потрудиться — зайти с определнной вкладки и там снять все фильтры, которые настойчиво рекомендуют брать B или D серию.
        Возможно, что A серия дороже, потому что она стоит на более старом оборудовании и ее специально сделали дороже, чтобы ее никто не покупал и со временем вывести это устаревшее железо.


      1. masyan
        11.02.2019 18:51
        #19743388

        image

        не вижу проблемы и внизу еще n-листов на любой вкус и цвет.
        надо ssd? докинул фильтр. надо gpu? докинул фильтр.


        1. onlinehead Автор
          11.02.2019 19:23
          #19743554

          А где в этом списке то именно 4vCPU и именно 8Гб памяти-то?


          1. masyan
            11.02.2019 19:27
            #19743590

            image


            1. onlinehead Автор
              11.02.2019 19:33
              #19743632

              Окей, там есть F4s. Могу сделать ретест на нее. Там есть еще F4s_v2, но Azur мне говорит что она мне недоступна с моей подпиской. Странно, ну да ладно.
              P.S. В списке и A-тип обозначен как General purpose, что ну никак не намекает на то, что они слабые.


  1. mvs
    11.02.2019 18:53
    #19743398

    Покажите, пожалуйста, latency из fio.


    1. onlinehead Автор
      11.02.2019 20:37
      #19743878

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


  1. DikSoft
    11.02.2019 19:58
    #19743746

    Есть любопытный сервис: Azure Price Calculator. Он подсказывает, что для 4 core + 8 Gb + 50 Gb SSD подходит машина F4s_v2.
    Можно её замерить для сравнения?


    1. onlinehead Автор
      11.02.2019 20:09
      #19743790

      Можно F4s, про v2 говорит что «он недоступен по моей подписке».


      1. SychevIgor
        11.02.2019 21:17
        #19744042

        скорее всего причина в этом docs.microsoft.com/en-us/azure/azure-supportability/resource-manager-core-quotas-request нужно лимит на ядра увеличить.
        хотя какая у Вас подписка- не мне не известно. если free trial — то это может быть и не лечится.


        1. onlinehead Автор
          11.02.2019 21:45
          #19744148

          нужно лимит на ядра увеличить.

          Ядер то столько же — 4, тип инстанса другой. Возможно ограничение триала, да. А может что-то еще. Но тем не менее я делаю ретест с использованием F4s. По производительности там все неплохо, но в пересчете на деньги все равно печально.


    1. Areso
      11.02.2019 20:33
      #19743854

      Как люди вообще в облака переезжают? Цена за 1 месяц в RI3 (чего бы это не значило) сопоставима с ценой сервера на вторичном рынке.


  1. stekov27
    11.02.2019 23:41
    #19744504
    +1

    Можно написать новый пост, о скорости возгорания и бомбления) и опять MS в лидерах)


  1. onlinehead Автор
    12.02.2019 00:16
    #19744598

    masyan, SychevIgor, olegfil, zolti — после ваших сообщений я подумал и переделал тест в части Azure. Не сказать, чтобы ему это сильно помогло, итоговый расклад не поменяло, но все что смог — то сделал.


    1. olegfil
      12.02.2019 14:35
      #19746814

      Спасибо! С учетом того что у Вас используется не самый современный F4s (он на Haswell) вместо F4sv2 (они на Skylake) при этом F4sv2 дешевле на 10% своего предшественника можно апроксимировать снижение показателя «рубль за попугай» примерно на 15-20% и тогда на 4х ядерной загрузке ситуация несколько поменяется — Azure обойдет и AWS и GCE.
      Хотя в целом Azure она про другое — это больше PaaS платформа и на нескольких последних проектах мы использовали виртуалки только в качестве билд-агента или для того чтобы «накидать» их в кластер Кубернетис или Service Fabric.


      1. gecube
        12.02.2019 14:47
        #19746876

        olegfil как я понимаю, Вы — постоянный пользователь Azure. Как Вы относитесь к следующим утверждениям?



        1. olegfil
          12.02.2019 15:00
          #19746980

          Если в компании используется кубернетис ради кубернетис — то конечно Google Cloud будет самой правильной и самой свежей.
          Но если вам надо еще и БД с репликацией и DataLake и веб-морду и поиск какой-нибудь и еще и SSO интегрированное с корпоративной AD и что-нибудь еще подобное, то тут уже «свежесть» кубернетис не будет играть такой ведущей роли.
          Доклад этот я не видел, но в кратком описании я не вижу ни слова про Azure, поэтому ничего не могу сказать.


          1. gecube
            12.02.2019 15:03
            #19746996

            Все остальное, кроме интеграции с корпоративной АД — есть и в Amazon, и в Google.
            Второй момент — а так ли нужен АД для серверов, при условии нормального configuration managemement?

            поиск

            это просто мега-аргумент, учитывая, что Гугл — поисковый гигант. Это не означает, что они зарелизили свой поиск для клиентов внутри своего облака, но доказывает их потенциал.


            1. olegfil
              12.02.2019 15:20
              #19747122

              В Azure AD там уже далеко не просто AD для пользователей — там система управления доступа между приложениями тоже. То есть на сервере будет крутится webAPI и можно настроить какие клиентские приложения будут коннектится к этому API и/или какие пользователи могут ими пользоваться предварительно залогинившись в front-end приложении. БД они сейчас тоже потихоньку под эту идеологию подтягивают.
              Это про AD.
              Теперь к релегиозным вопросам.
              А почему не Azure? Потому что Microsoft?
              Мне лично нравятся продукты Microsoft для разработчиков — c# отличный язык, MS SQL вполне себе нормальная БД, Visual Studio нормальная среда разработки (еще и бесплатная).
              Мне, честно говоря, даже MacOS меньше нравится чем Win10 (но тут наверно дело привычки, хотя после несколько дней за MacOS у меня не случилось просветления)
              Я работал с AWS существенно меньше чем с Azure, но мне чаще приходилось обращаться в поддержку. Хотя с другой стороны виртуалка в AWS работает удивительно стабильно — месяцами не перегружается.


              1. gecube
                12.02.2019 15:32
                #19747202

                Мне лично нравятся продукты Microsoft для разработчиков — c# отличный язык, MS SQL вполне себе нормальная БД, Visual Studio нормальная среда разработки (еще и бесплатная).

                Java (уже приходится), Postgres или Oracle, IntelliJIDEA. Я думаю, понятно, к чему я клоню, да?
                Мне, честно говоря, даже MacOS меньше нравится чем Win10 (но тут наверно дело привычки, хотя после несколько дней за MacOS у меня не случилось просветления)

                после линукса — MacOS X заходит норм. И уж точно не Вин10.
                В Azure AD там уже далеко не просто AD для пользователей

                Вы бы уточнили о чем идет речь. И да, я в курсе, что Azure AD - это уже БОЛЬШЕ, чем классический AD на виндовс-серверах. Но IAM (это то, что Вам нужно) — есть в любом облаке…

                P.S.
                А почему не Azure? Потому что Microsoft?

                Еще спросите — почему я адепт не гитхаба, а гитлаба.


                1. olegfil
                  12.02.2019 15:41
                  #19747270

                  Не — не понимаю к чему Вы клоните.
                  Я прекрасно общаюсь с Linux серверами и разрабатываю на JS и немного Python (это мой 8й язык программирования на котором я делал коммерческие приложения).
                  «Но IAM (это то, что Вам нужно)» — откуда Вы знаете что мне нужно? Меня часто спрашивают про возможности Azure AD с целью продать ее клиентам — мнгоим она отлично заходит и является одной из причин выбора Azure.
                  Объясните, почему надо использовать Java, а не .NET Core и С#? Почему надо использовать дорогущий Oracle, а не MS SQL? (раобтал с обеими)
                  Хотя можете и не объяснять — это чисто антропологический интерес.
                  Мы обсуждаем релегиозные вопросы, а разработка ПО — она про деньги.
                  И вот в этом разрезе Azure сейчас интенсивно растет потому что предлагает лучше за те-же деньги.


                  1. gecube
                    12.02.2019 15:48
                    #19747332

                    Я к тому, что мы представители разных лагерей. Я скорее начну писать на Java (тоже себе вполне язык коммерческой разработки, как и C#), чем переметнусь на сторону зла… простите, M$.

                    откуда Вы знаете что мне нужно?

                    Я к тому, что есть альтернативные продукты. Мир не черно-белый, к счастью. И все крупные вендоры пытаются примерно сделать одно и то же.
                    Почему надо использовать дорогущий Oracle, а не MS SQL? (раобтал с обеими)

                    Потому что Oracle умеет в RAC? MSSQL давно научилось нормально кластеризоваться (без костылей)? Опять же не хочу скатываться в кровавые споры и предлагаю не полемизировать.

                    P.S. из всего многообразия клиентов вокруг меня — нет НИ одного на Azure. Я допускаю, что вся масса Azure реализуется несколькими большими компаниями. Все больше на слуху Amazon. Единственное, что реально меня порадовало в Azure — наличие AzureStack, но пока что в РФ есть только один провайдер, который может его предоставить, да и то — весьма условно.


                    1. olegfil
                      12.02.2019 15:59
                      #19747412

                      Ну вот к счастью мир не черно белый и я с большим удовольствием пользуюсь MS стеком, хотя работал и с другими.
                      И вокруг меня МНОГО клиентов на Azure, хотя среди разработчиков, у которых я преподаю в школе архитекторов, любимый облачный провайдер это AWS.
                      И да клиенты с Azure — это крупные компании входящие в Top10 в своих сферах. B обычно у них используется еще и AWS и еще и собственный ЦОД.


    1. SychevIgor
      13.02.2019 08:24
      #19749902

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


  1. stekov27
    12.02.2019 19:26
    #19748444

    Хотя с другой стороны виртуалка в AWS работает удивительно стабильно — месяцами не перегружается.


    И вот в этом разрезе Azure сейчас интенсивно растет потому что предлагает лучше за те-же деньги.

    как-то вы сами себе противоречите.


    1. olegfil
      12.02.2019 20:34
      #19748680

      Потому что переезд в облака он не только про виртуалки. Если нужен просто IaaS на десяток виртуалок, то тут AWS может быть предпочтительнее, хотя скорее всего выйдет немного дороже.
      Если PaaS/SaaS то тут уже Azure имеет более сильные позиции с более широким или более дешевым выбором, интеграциями корпоративных инструментов(AD,Office) и гибридными облаками в том числе и для БД и для всяких систем бэкапов.


      1. stekov27
        12.02.2019 22:19
        #19749008

        кроме интеграции с офисом — который кмк, не про сервера вовсе и инфраструктуру, я что-то плюсов не вижу. Про AD выше уже ответили.


        1. olegfil
          12.02.2019 22:52
          #19749110

          А у вас реально есть потребность в облаках? Или в смене поставщика? У вас реально есть где-то проблема которую нужно решать? Вы являетесь ЛПР в этом вопросе?
          Если нет утвердительных ответов на эти вопросы — то разговор идет о сферических конях в вакууме и смысла он не имеет.


          1. stekov27
            13.02.2019 00:49
            #19749412

            Реально есть потребность в облаках. Устраивают оба провайдера) И да, я решал какие будут облака. Если б проблем не было — их нужно было придумать и развиваться дальше, а не сидеть и «2 руками радоваться» как из офисного MS легко вкатиться в azure.
            И опять же, если б у вас так не подгорело, никто б и не продолжал вас дразнить)
            Уважаемые, Любители стеклопакетов…
            P.S. попробуйте выйти из зоны комфорта.


        1. gecube
          13.02.2019 07:57
          #19749848

          Помимо MS офиса у MS есть еще G-Suite у Гугла… Но это так, к слову.


  1. IgorPie
    12.02.2019 20:37
    #19748690

    С учетом последних трендов законописания, я бы попросил поделить сервисы по стороны железного занавеса.
    Нашей скромной артели сейчас сервисы для иностранцев придется переводить на иностранные сервера, а для РФ — на российские, т.к. не хочется, чтобы при закрытии великого фаерволла иностранные пользователи остались без сервисов, которые пока что крутятся в РФ.