Например fio. Скажите что и как потестить - скину.
fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=4G --readwrite=randwrite
iops : min= 316, max=17948, avg=12848.71, stdev=3631.87, samples=163 cpu : usr=2.66%, sys=13.01%, ctx=761779, majf=0, 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 rwt: total=0,1048576,0, short=0,0,0, dropped=0,0,0 latency : target=0, window=0, percentile=100.00%, depth=64
fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=4G --readwrite=randread
iops : min=19746, max=61402, avg=21334.18, stdev=6347.08, samples=98 cpu : usr=2.37%, sys=12.12%, ctx=235928, majf=0, minf=92 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 rwt: total=1048576,0,0, short=0,0,0, dropped=0,0,0 latency : target=0, window=0, percentile=100.00%, depth=64
P.S. Для тех кто в танке, это отказоустойчивый распределенный сторадж, любые данные пишутся и хранятся одновременно минимум на 3 физических стораджа, один из которых в другом датацентре.---------- Добавлено 23.10.2018 в 15:35 ----------
Амазон в принципе не заточен под мелкий средний бизнес. И он им не интересен.
Плюс амазона в относительной надежности и доступности ресурсов, в том числе под разные задачи (всякие там GPU optimized и прочее). Идеален для enterprise уровня, которые в любом случае строят архитектуру и решения сами.
Минус амазона как и ажура и гугла - любые managed услуги начинаются от 15 тысяч долларов. Никто Вам не будет разжевывать, почему у вас виртуальная машина упала, или почему нужно кластеры делать из баз. Высокая стоимость, тарификация всего и вся. Им интересно давать не IaaS а SaaS причем с vendor lock (всякие dynamodb).
Это зависит от реализации конкретных решений, маркетинг тут не причем.
В типовой стандартной ситуации все что требуется для работы приложения в облаке - это убедится что все сервисы стоят в autoboot. Чтобы в случае ситуации когда в облаке падает физическая нода и виртуальная машина/контейнер стартует на другой оборудовании, у него все стартануло как нужно.
Второе что нужно помнить - это приложения которые держат данные в памяти. Классический пример - базы данных. В этой ситуации есть вероятность что они не поднимутся после такого рестарта. Решается использованием SaaS готовых решений (как у амазон) или созданием собственных кластеров (например тот же Galera из 3 нод). Опять же отсылаю на запись конференции, там как раз об этом речь и идет. Или если из Москвы приходите в ноябре https://www.devopspro.ru/andrey-nesterenko/ где будет об этом же речь.
Это не проблема облака как такового, и этим нужно заниматься независимо от выбора способа хостинга.
Отвечу тут, скрывать как бы нечего, надеюсь будет интересно другим тоже.
* По производительности стораджа. Собственно об этом статья на хабре, у нас есть 2 уровня дисковой производительности.
По умолчанию, все контейнеры, запущенные на облачной платформе, получают дисковую производительность первого уровня «Базовый Storage» - Tier I: disk.io - до 250 Mb/s; iops – до 200 o/s. Стоимость: 0,01 руб/час. Первые 10 Гб в каждом окружении бесплатно.
Более высокие показатели дисковой производительности можно получить, заказав услугу «Премиум Storage» для выбранных контейнеров - Tier II: disk.io - до 400 Mb/s; iops - до 20 000 o/s. Стоимость: 0,03 руб/час
Важные моменты:
- Оплата идет по факту использования места. Сколько реально Гб используете каждый час столько и списывается.
- Окружений может быть несколько. На каждый изначально дается первые 10 Гб места бесплатно базового стораджа
- Включать и выключать премиум сторадж можно на каждый контейнер (которых может быть несколько в рамках одного окружения)
- i/o лимиты даются на каждый контейнер. Если у нас кластер из 3 MySQL на премиум сторадже, то каждый контейнер получается до 20к iops.
Проблемы шумных соседей и в целом производительности сторадж решаются лимитами на каждый контейнер (то что я написал выше), а также увеличение количество чанк серверов (т.е. количество физических ssd/nvme). Чем их больше тем больше общая производительность.
Калькулятор на сайте дает индикацию и не предназначен для получения каких-то финальных цен, ибо их невозможно получить в таком виде по определению.
Именно поэтому мы предлагаем бесплатный триал на 2 недели, в течении которых можно спокойно поставитьи оценить реальные нагрузки и их стоимость. Для более сложных проектов мы готовы предоставлять расширенные пробные периоды вплоть до 90 дней.
CPU usage работает по CGroup лимитам и данным реального потребления CPU в контейнерах и соответствено от этого считается и потребление. Если у Вас не специфические проекты на CPU (типа майнинг или какие-то вычисления) то вряд ли Вы будете упираться в CPU в принципе. В любом случае, пока не протестируете реально - сказать мало чего можно.
И последнее, под разные задачи есть разные решения. Есть задачи, под которые будет лучше поставить распределенно кучку серверов с локальными nvme для создания кластеров на уровне приложения. Другими словами, частное облако, на выделенном оборудовании. Ну и наоборот, есть задачи где виртуального хостинга с головой.
E3-1230v3-v6, 16G RAM, 2x120G SSD RAID1, безлимитный гигабит - 250 евро
Нидерланды, AS52000
Отказоустойчивость прямого отношения к облаку не имеет как правильно уже написали.
Другое дело, что без настоящего HA настоящего же облака и не получится, поэтому это само собой подрузамевается.
Смотрите сами, чтобы клиент мог в любой момент запросить потенциально любое количество ресурсов, это значит что
А) - У хостера должно быть доступное количество свободное ресурсов
Б) - Должен быть оркестратор, который динамически может выполнять миграции ресурсов клиента в зависимости от текущей нагрузки.
Чтобы оба пункта работали, облачная платформа должна быть на отказоустойчивых технологиях, прежде всего по стораджу. Локальный сторадж тут никак не будет работать.
Если интересно технические детали, можно почитать тут: https://habr.com/company/jelastic/blog/342278/
Еще можно послушать про отказоустойчивость тут: https://www.youtube.com/watch?v=OuX1AuKRx20
Но это больше для девопсов как строить свои кластеры и решения.---------- Добавлено 21.10.2018 в 12:12 ----------
Это горизонтальное масштабирование. Добавление / удаление инстанций в зависимости от правил по нагрузке.
К оплате по факту используемых ресурсов это не имеет отношения.
Да, есть. Смотрите подпись.
Да, в 90% то что называют облаком таким не является.
В лучшем случае это как у амазон фиксированные инстансы, которые можно запускать и стопать по необходимости, оплачивая по времени использования.
Кроме оплаты по фактически используемым ресурсам должна быть возможность использовать любое количеством ресурсов в любое время в автоматическом режиме.
И да, в настоящем облаке провайдеру невыгодно органичивать и зажимать ресурсы, как это делается на обычных впс, ибо пользователь платит за используемые ресурсы. А если он их не может использовать то он меньше платит, что не выгодно провайдеру. Что разумеется хорошо для пользователя.
А вот касательно стабильности, качества и всего остального - тут какие технологии не используй, все зависит от провайдера и качества его услуг.---------- Добавлено 20.10.2018 в 23:46 ----------
Зависит от реализации. Если говорить про то как это сделано у нас, просто каждый час списываются средства по факту использования за конкретный час. Было больше - списалось больше. Было меньше - списалось меньше.
В любом случае всегда есть максимальный лимит ресурсов, выше которого это не выйдет, чтобы не беспокоиться.
Как показывает практика, подавляющее большинство клиентов очень сильно экономят по сравнению с традиционными услугами, ибо обычно приходится покупать ресурсы с запасом. И даже несмотря на то что ресурсы в облаке стоят обычно дороже чем традиционные впс, в конечном итоге получается экономия.
Гугл не анонсит свои IPv6 в Cogent и некоторые другие сети в штатах. Соответственно доступ по IPv6 через этих транзитов не будет.
От других прилетит только тех, которым гугл анонсит. Через zayo у нас проходит.
100$ маловато за 100 Тб трафика в месяц
E3-1230v2, 16G, 2x1Tb WD Black - 150$
Сервер в стойке, готовы предоставить в любое время
Анонс своих сетей сделаем
AS52000
Давайте. Предложите.
Я предложил реальный вариант, исходя из того что ТС написал что ему в перспективе нужно 3-4 конфигурации. И кстати да, если на долгосрочное то через месяцев 6 можно будет еще снизить.
Умельцы торговать? Это предложение по цене трафика, это демпинг по сути. Просто потому что каналы простаивают и железо есть свободное. Исходя из Вашей логики, это скорее неумельцы торговать :)
Мне интересно только что, что ТС пишет про долгосрочное сотрудничество.
Кстати ТС, Вы пишите про стрим, так вот, если будете ставить туда Wowza, то можно будет за те же деньги дать 1275 v5, на которых через quicksync почти в 3 раза улучшается производительность транскодеров.
Как вариант, можно дать полный 1 гигабит (грубо говоря 300 Тб в месяц, т.е. 3 штуки) на выделенном сервере вида E3-1230v3-v6, 16G RAM, 2x120G SSD RAID1 в Нидерландах. Поставим туда виртуализацию, будет 3 VPS (ну или сколько нужно), за 250 евро. Можно дать на пару дней бесплатно тест, если что-то хотите что-то тестить.
Собственное оборудование, собственный микс трафика: https://bgp.he.net/AS52000#_peers
