Comments 48
Статья ни о чем.
Во-первых, тот же Селектел предлагает несколько разных услуг. Начиная от простых ВМ vScale и кончая полными «облачными инфраструктурами». Причем последние есть как на базе OpenStack (по сути полностью публичное облако Селектела), так и на vmware (не тестировал плотно).
Дополнительно — ценники и спецификации на OpenStack тут selectel.ru/services/cloud/vpc/?dedicatedab=true
Что понравилось — действительно IOPS на накопители ограничиваются и они насколько это возможно гарантированы VM. Понятно, что между IOPS и скоростью (чтения, записи, в МБ/сек) есть прямая зависимость, но возможен кейс, когда софт не полностью утилизирует пропускную способность, хотя IOPSы в потолок. Поэтому тут нужно подходить очень аккуратно.
Касательно возможности выбора процов — вообще впервые слышу, никогда особо это проблемой не было.
Во-первых, тот же Селектел предлагает несколько разных услуг. Начиная от простых ВМ vScale и кончая полными «облачными инфраструктурами». Причем последние есть как на базе OpenStack (по сути полностью публичное облако Селектела), так и на vmware (не тестировал плотно).
Дополнительно — ценники и спецификации на OpenStack тут selectel.ru/services/cloud/vpc/?dedicatedab=true
Что понравилось — действительно IOPS на накопители ограничиваются и они насколько это возможно гарантированы VM. Понятно, что между IOPS и скоростью (чтения, записи, в МБ/сек) есть прямая зависимость, но возможен кейс, когда софт не полностью утилизирует пропускную способность, хотя IOPSы в потолок. Поэтому тут нужно подходить очень аккуратно.
Касательно возможности выбора процов — вообще впервые слышу, никогда особо это проблемой не было.
Во-первых, тот же Селектел предлагает несколько разных услуг. Начиная от простых ВМ vScale и кончая полными «облачными инфраструктурами». Причем последние есть как на базе OpenStack (по сути полностью публичное облако Селектела), так и на vmware (не тестировал плотно).
Вскейл, конечно, аффилированная с селектелом контора, но это скорее просто бюджетный хостер виртуалок, чем полноценное облако. В статье рассматривается именно VPC.
Касательно возможности выбора процов — вообще впервые слышу, никогда особо это проблемой не было.
Не то, чтобы их можно было выбирать у каждого хостера из разных вариантов, конечно. Но понимать, какое железо крутится под твоей виртуалкой бывает полезно. И, возможно, кому-то будет важно выбрать более производительный проц.
Я уж не говорю про
простите — терабит, терабайт или терибайт (ТиБ)?
Все-таки мы в русскоязычной среде и логично использовать кириллические аббревиатуры, желательно — максимально однозначные. И так по всей статье. Говорю же — сырая.
P.S. уже поправили, но все равно в одном месте — «более 150 TB», в другом — «до 10 ТБ», а в таблице в конце — «Тб»
до 10 Tb
простите — терабит, терабайт или терибайт (ТиБ)?
Все-таки мы в русскоязычной среде и логично использовать кириллические аббревиатуры, желательно — максимально однозначные. И так по всей статье. Говорю же — сырая.
P.S. уже поправили, но все равно в одном месте — «более 150 TB», в другом — «до 10 ТБ», а в таблице в конце — «Тб»
В свою очередь, когда под конец речь идет про конфигу «среднего уровня интернет-магазина, находящегося у нас на поддержке», зачем говорить по облако, если задача как раз отлично ложится на виртуалку, или на выделенный сервер (возможно, с намазанной сверху виртуализацией)? Я рассуждаю в пределах запрошенных ресурсов и в пределах указанных цен.
И, да, облака в России есть не только у перечисленных компаний, более того, у некоторых из них облака — не основной вид бизнеса. В то же время МТС (купивший ИТ-Град за 2,5 млрд рублей), например, как-то забыли привести — а у них, на сегодня, есть и облако МТС, и облако ИТ-Града (сужу как внешний наблюдатель).
По поводу простоты администрирования: арендованный виртуальный или физический сервер выдаётся в руки точно так же, как виртуалка в облаке, и администрируется сравнимо (т.е. облако не сказать чтобы проще, т.к. внутри тот же линукс, грубо говоря). А если учитывать дополнительный объем навыков работы с самим облаком (хотя в описываемом подходе это и не сильно критично: по описанию ничем «облачным», вроде автомасштабирования, мы тут не связаны), то, в чем-то, облако покажется и сложнее.
Облака суперинтересны, когда всплывает разговор про API, про автоматизацию, но — про это как раз ни в описании, ни в тесте не говорится. Вот тест того, как скоро сервер при проблемах облака оживает — это, да, было бы интересно. Правда, осталось еще смоделировать проблему, чтобы облако смогло отработать! *смайлик*
И, да, облака в России есть не только у перечисленных компаний, более того, у некоторых из них облака — не основной вид бизнеса. В то же время МТС (купивший ИТ-Град за 2,5 млрд рублей), например, как-то забыли привести — а у них, на сегодня, есть и облако МТС, и облако ИТ-Града (сужу как внешний наблюдатель).
По поводу простоты администрирования: арендованный виртуальный или физический сервер выдаётся в руки точно так же, как виртуалка в облаке, и администрируется сравнимо (т.е. облако не сказать чтобы проще, т.к. внутри тот же линукс, грубо говоря). А если учитывать дополнительный объем навыков работы с самим облаком (хотя в описываемом подходе это и не сильно критично: по описанию ничем «облачным», вроде автомасштабирования, мы тут не связаны), то, в чем-то, облако покажется и сложнее.
Облака суперинтересны, когда всплывает разговор про API, про автоматизацию, но — про это как раз ни в описании, ни в тесте не говорится. Вот тест того, как скоро сервер при проблемах облака оживает — это, да, было бы интересно. Правда, осталось еще смоделировать проблему, чтобы облако смогло отработать! *смайлик*
Облака суперинтересны, когда всплывает разговор про API, про автоматизацию, но — про это как раз ни в описании, ни в тесте не говорится.
Об этом говорит первый же абзац, если вам довелось его прочитать:
Причина проста — кроме вычислительных мощностей бизнесу уже недостаточно одной лишь командной строки для управления «хозяйством». Нужно и удобство управления инфраструктурой и, что немаловажно, возможность его автоматизации.
Про доступность API и соответствующие релевантные ссылки написано ещё чуть дальше в отдельном подразделе.
Цель статьи — именно сравнение соотношения мощность/ценник, чтобы понимать, куда податься тому, кто знает, зачем ему облако. А не затем, чтобы объяснить, кому оно нужно, а кому нет.
И в данном контексте, честно говоря, плохо понимаю зачем уводить дискуссию в совершеннейший оффтоп.
И, да, облака в России есть не только у перечисленных компаний, более того, у некоторых из них облака — не основной вид бизнеса. В то же время МТС (купивший ИТ-Град за 2,5 млрд рублей), например, как-то забыли привести — а у них, на сегодня, есть и облако МТС, и облако ИТ-Града (сужу как внешний наблюдатель).
хочу еще добавить, что в МТС еще внутри есть куча с одной стороны конкурирующих, а с другой — взаимодополняющих продуктов. Стоит сказать про AzureStack, например. А еще тут на подходе Сберклауд. Незаслуженно пропустили ActiveCloud — они еще 10 лет назад были. Ну, и есть, конечно, все еще облака от КРОК, Техносерв и пр. — легион им имя.
Поддержу.
Товарищ fwm, у меня несколько вопросов:
1. Сколько было итераций для получения каждой цифры?
2. Сколько машин проверялось в каждом клауде?
Плюс, у вас цифры со скриншотов не бьются с теми, что в таблице. Посмотрите на stress-ng тест, значений со скрина нет в таблице. Что это было?
Сомнения у меня большие в этом тесте, ой большие. Не заказуха ли?
Кстати, у меня есть некоторое кол-во машинок (в разных зонах доступности) в Я.Облаке для одного проекта и я решил прогнать ваши тесты (отдельное «спасибо» за ключи запуска на скриншотах вместо текста).
Все машинки 100%, 2CPU/2GB, нагрузка в виде Kubernetes-мастеров со всей обвязкой не выгружалась. Машинки в разных зонах доступности.
Вот что получилось:
Для второго сервера:
Сводными данными:
1. В один поток на одном сервере 9596 средняя, на другом 10131. Даже с учетом фоновой ненулевой нагрузки.
2. В два потока на двухядерных машинах даже МЕДЛЕННЕЕ, чем в один. Вероятно потому, что продаются потоки исполнения процессоров, а не честные физические ядра.
Расскажете, как получились ваши результаты?
P.S. На этих машинках какой то Haswell с 2ГГц на ядро, точнее из системы не видно.
Товарищ fwm, у меня несколько вопросов:
1. Сколько было итераций для получения каждой цифры?
2. Сколько машин проверялось в каждом клауде?
Плюс, у вас цифры со скриншотов не бьются с теми, что в таблице. Посмотрите на stress-ng тест, значений со скрина нет в таблице. Что это было?
Сомнения у меня большие в этом тесте, ой большие. Не заказуха ли?
Кстати, у меня есть некоторое кол-во машинок (в разных зонах доступности) в Я.Облаке для одного проекта и я решил прогнать ваши тесты (отдельное «спасибо» за ключи запуска на скриншотах вместо текста).
Все машинки 100%, 2CPU/2GB, нагрузка в виде Kubernetes-мастеров со всей обвязкой не выгружалась. Машинки в разных зонах доступности.
Вот что получилось:
#### 1 CPU, Server 1, iter 1
stress-ng --cpu 1 --cpu-method matrixprod --metrics-brief -t 60
...
stress-ng: info: [29104] stressor bogo ops real time usr time sys time bogo ops/s bogo ops/s
stress-ng: info: [29104] (secs) (secs) (secs) (real time) (usr+sys time)
stress-ng: info: [29104] cpu 9577 60.00 59.54 0.24 159.61 160.20
#### 1CPU, Server 1, iter 2
stress-ng --cpu 1 --cpu-method matrixprod --metrics-brief -t 60
...
stress-ng: info: [1585] stressor bogo ops real time usr time sys time bogo ops/s bogo ops/s
stress-ng: info: [1585] (secs) (secs) (secs) (real time) (usr+sys time)
stress-ng: info: [1585] cpu 9616 60.00 59.54 0.24 160.26 160.86
#### 2 CPU, Server 1, iter 1
stress-ng --cpu 2 --cpu-method matrixprod --metrics-brief -t 60
...
stress-ng: info: [31641] stressor bogo ops real time usr time sys time bogo ops/s bogo ops/s
stress-ng: info: [31641] (secs) (secs) (secs) (real time) (usr+sys time)
stress-ng: info: [31641] cpu 8795 60.01 111.70 0.69 146.56 78.25
#### 2CPU, Server 1, iter 2
stress-ng --cpu 2 --cpu-method matrixprod --metrics-brief -t 60
...
stress-ng: info: [32419] stressor bogo ops real time usr time sys time bogo ops/s bogo ops/s
stress-ng: info: [32419] (secs) (secs) (secs) (real time) (usr+sys time)
stress-ng: info: [32419] cpu 8743 60.01 112.04 0.67 145.70 77.57
Для второго сервера:
#### 1CPU, Server 2, iter 1
# stress-ng --cpu 1 --cpu-method matrixprod --metrics-brief -t 60
stress-ng: info: [27228] dispatching hogs: 1 cpu
..
stress-ng: info: [27228] stressor bogo ops real time usr time sys time bogo ops/s bogo ops/s
stress-ng: info: [27228] (secs) (secs) (secs) (real time) (usr+sys time)
stress-ng: info: [27228] cpu 10142 60.00 59.71 0.07 169.03 169.66
#### 1CPU, Server 2, iter 2
stress-ng --cpu 1 --cpu-method matrixprod --metrics-brief -t 60
...
stress-ng: info: [27944] stressor bogo ops real time usr time sys time bogo ops/s bogo ops/s
stress-ng: info: [27944] (secs) (secs) (secs) (real time) (usr+sys time)
stress-ng: info: [27944] cpu 10121 60.01 59.92 0.00 168.67 168.91
#### 2CPU, Server 2, iter 1
stress-ng --cpu 2 --cpu-method matrixprod --metrics-brief -t 60
...
stress-ng: info: [29059] stressor bogo ops real time usr time sys time bogo ops/s bogo ops/s
stress-ng: info: [29059] (secs) (secs) (secs) (real time) (usr+sys time)
stress-ng: info: [29059] cpu 9055 60.01 111.35 1.04 150.90 80.57
#### 2CPU, Server 2, iter 2
stress-ng --cpu 2 --cpu-method matrixprod --metrics-brief -t 60
...
stress-ng: info: [29702] (secs) (secs) (secs) (real time) (usr+sys time)
stress-ng: info: [29702] cpu 9084 60.00 111.53 0.95 151.39 80.76
Сводными данными:
1. В один поток на одном сервере 9596 средняя, на другом 10131. Даже с учетом фоновой ненулевой нагрузки.
2. В два потока на двухядерных машинах даже МЕДЛЕННЕЕ, чем в один. Вероятно потому, что продаются потоки исполнения процессоров, а не честные физические ядра.
Расскажете, как получились ваши результаты?
P.S. На этих машинках какой то Haswell с 2ГГц на ядро, точнее из системы не видно.
Плюс, у вас цифры со скриншотов не бьются с теми, что в таблице. Посмотрите на stress-ng тест, значений со скрина нет в таблице. Что это было?
КДПВ, скрины только для примера того, как вообще выглядят утилиты. Все полезные данные в таблицах.
По методике проведения тестирования чуть позже сегодня черкнём деталей
КДПВ, скрины только для примера того, как вообще выглядят утилиты
ну, это вообще, извините, звучит смешно. Могли их либо вообще отдельно вынести (парни, поглядите как выглядят утилиты!) или хотя бы снять их с реальных тестов )
Это не нагрузочное тестирование, а синтетические тесты.
Мне кажется более показательно было бы развернуть какое-то популярное приложение и через него уже подавать нагрузку.
Мне кажется более показательно было бы развернуть какое-то популярное приложение и через него уже подавать нагрузку.
Да, с «живым» битриксом (например, да хоть wordpress), конечно, было бы чуть интереснее, но всё равно синтетика, т.к. это либо его встроенным бенчмарком гонять, который довольно сильно далёк от объективности, либо гонять копию какого-то настоящего проекта по реплею логов. Чуть правдивее, но тоже характер нагрузки может сильно не совпадать с реальным.
Для максимально жизненного тестирования было бы круто настоящий живой проект раскидать по четырём одинаковым виртуалкам и балансить поровну запросы ко всем. И уже тогда смотреть по нагрузке. Но на такие эксперименты почему-то не сильно хотят соглашаться:)
Поэтому мы решили отбенчить непосредственно железо, какое предоставляют хостеры и сравнить между собой.
Для максимально жизненного тестирования было бы круто настоящий живой проект раскидать по четырём одинаковым виртуалкам и балансить поровну запросы ко всем. И уже тогда смотреть по нагрузке. Но на такие эксперименты почему-то не сильно хотят соглашаться:)
Поэтому мы решили отбенчить непосредственно железо, какое предоставляют хостеры и сравнить между собой.
Согласен, что на такие тесты надо согласовывать. Просто этими тестами для себя вы какое-то впечатление получили о производительности конкретных виртуалок, но выборка крайне мала. Мне не понятно как эти тесты помогут ответить на эти вопросы
Стандартный клиент не сможет сопоставить IOPS-ы о которых вы им скажете в понятную ему производительность и доступность его сервиса.
Про доступность и вовсе отдельный вопрос. Как будут меняться времена отклика от сервиса в зависимости от времени суток/дня недели/месяца и т.п. На такие тесты было бы интересно посмотреть, да и Вам было бы что аргументированно отвечать клиентам.
Вопросы эти более чем обыденные: какой хостинг выбрать, в каком регионе, что решать с конфигурацией.
Стандартный клиент не сможет сопоставить IOPS-ы о которых вы им скажете в понятную ему производительность и доступность его сервиса.
Про доступность и вовсе отдельный вопрос. Как будут меняться времена отклика от сервиса в зависимости от времени суток/дня недели/месяца и т.п. На такие тесты было бы интересно посмотреть, да и Вам было бы что аргументированно отвечать клиентам.
Стандартный клиент не сможет сопоставить IOPS-ы о которых вы им скажете в понятную ему производительность и доступность его сервиса.
Конкретно в нашем случае это решается тем, что у нас уже есть данные о том, как ведёт себя система клиента, какие там узкие места. Даже для только пришедших новых клиентов мы всегда заявляем, что хотя бы неделю-две надо помониторить все сервисы, посмотреть, где во что упирается проект. И уже на основе этих данных и того, что мы заранее потестировали у хостеров, можем как-то рекомендовать, куда бы лучше переехать. Если конечно такая потребность имеется.
Про доступность и вовсе отдельный вопрос. Как будут меняться времена отклика от сервиса в зависимости от времени суток/дня недели/месяца и т.п. На такие тесты было бы интересно посмотреть, да и Вам было бы что аргументированно отвечать клиентам.
Это прямо очень классный запрос! Но, к сожалению, пока многие опасаются держать прод на мало пока известных и проверенных площадках, поэтому выборка лично у нас получится не очень репрезентативной на данный момент.
Но, возможно, в том числе и эта статья поможет людям понять, что, на самом деле, нет явно плохих или явно хороших площадок, у каждой свои плюсы и минусы. И, возможно, чуть позже мы сможем и долгосрочную статистику по доступности/надёжности собрать:)
Но, возможно, в том числе и эта статья поможет людям понять, что, на самом деле, нет явно плохих или явно хороших площадок, у каждой свои плюсы и минусы.
золотые слова. А если еще учесть старания маркетологов, то мы поймем, что качество каждой площадки в рамках одного региона будет в прямой зависимости от стоимости услуг.
Самое интересное, что я тоже делал синтетические тесты. Т.е. брал сферическую в вакууме монгу, натравливал на нее github.com/brianfrankcooper/YCSB и смотрел разницу. Ну, в целом — что виртуалка в локальном частном облаке на vmware, что селектел, что yandex давали ± одну производительность. Единственный, кто вырвался вперед — мой рабочий ноутбук )))) Т.е. получается, что все эти виртуальные инфраструктуры можно измерять в неких стандартных единицах неких стандартных серверов.
Тестирование IOPS блоками в 512 очень странно. Стандартный размер блока 4К. Учитывая сколько IOPS показали servers и яндекс, думаю предлагаемые технологии внутри очень различны. Servers предоставляет трехкратную репликацию в разные зоны доступности? Если нет, то сравнение и выводы тем более некорректны.
Учитывая сколько IOPS показали servers и яндекс, думаю предлагаемые технологии внутри очень различны. Servers предоставляет трехкратную репликацию в разные зоны доступности?
Совершенно не исключаем того, что внутри оно может быть устроено различно. Но, к сожалению, в информационных и рекламных материалах о таких деталях пишут крайне редко. У вас есть какие-то данные более подробные на эту тему? Которые могли бы подтвердить соответствующие представители компаний, перечисленных в статье? С радостью дополним, в таком случае, статью:)
Про яндекс у них была презентация, видео и тп. Поэтому нет смысла спрашивать их комментарии.
Селектел вроде ceph использовал, но могу уже подзабыть. MCS на сколько помню, вроде тоже Ceph. А вот что с servers не знаю.
Селектел вроде ceph использовал, но могу уже подзабыть. MCS на сколько помню, вроде тоже Ceph. А вот что с servers не знаю.
Мне кажется, что потребителю от того, как устроено облако внутри ни тепло, ни холодно. Потребителя интересуют «внешние интерфесы» облака — насколько удобна и стабильна панель, охват услуг, стоимость и пр. А внутри — хоть техподдержка руками пускай виртуалки запускает ))))
Другой вопрос — риски и их оценка. Но это больше вопрос договорных отношений, чем технологичности.
p.s. меня как «гика» естественно интересует наиболее полная информация, т.е. ВСЕ, но это частный случай.
Другой вопрос — риски и их оценка. Но это больше вопрос договорных отношений, чем технологичности.
p.s. меня как «гика» естественно интересует наиболее полная информация, т.е. ВСЕ, но это частный случай.
Это зависит от технической грамотности потребителя. Как правильно заметили, локальный комп с ссд даст иопсов больше, так может всех надо на таких размещать? Только когда один ссд сдохнет, поздно будет оправдываться тем, что я же не знал как оно устроено.
Вы не правы. Потому что потребитель — он должен выставлять требования. Ну, там по отказоустойчивости, по доступности и пр. Только он знает свою предметную область на 100%. А мы как технические специалисты можем посоветовать как эти требования удовлетворить и за какую сумму.
Условно — локальный ноутбук для целей разработки вполне подойдет. Сломается? Да и пофиг, запустим разработку/тесты на соседнем. А продакшн — да, на такое страшно тащить.
Касательно облака — вот все думают, что оно прям отказоустойчиво, все данные бекапятся и т.д. Это обывательская и неверная точка зрения. Потому что действительно разработчики и провайдеры облака предусмотрели многие кейсы, но вот все равно те же бекапы (хотя бы подключение их как услуги) — лежит на плечах потребителя.
Условно — локальный ноутбук для целей разработки вполне подойдет. Сломается? Да и пофиг, запустим разработку/тесты на соседнем. А продакшн — да, на такое страшно тащить.
Касательно облака — вот все думают, что оно прям отказоустойчиво, все данные бекапятся и т.д. Это обывательская и неверная точка зрения. Потому что действительно разработчики и провайдеры облака предусмотрели многие кейсы, но вот все равно те же бекапы (хотя бы подключение их как услуги) — лежит на плечах потребителя.
Да, облака… Если сравнить с арендой серваков (тем же chipcore от Селектела), получается тройной ценник за более низкую производительность.
Да, действительно, чисто за производительность железки выходят экономичнее виртуалок любого рода. Но железки и обслуживать конечному пользователю сложнее.
Но безотносительно этого всего, конкретно на чипкоре я бы держать прод не рекомендовал бы. Это очень явный лоукост с соответствующим уровнем предоставляемых услуг.
Но безотносительно этого всего, конкретно на чипкоре я бы держать прод не рекомендовал бы. Это очень явный лоукост с соответствующим уровнем предоставляемых услуг.
Что вы имеете в виду под «обслуживать»? По чипкору я так понимаю это тот же селектел, но ограничены методы оплаты и конфигурации на десктопных процах (еще меньше трафика, чем в обычном Селектеле), не думаю, что там есть какая-то разница в уровне услуг…
Что вы имеете в виду под «обслуживать»
Всё, что, собственно, можно под этим подразумевать. Чинить, апгрейдить, даунскейлить. Условно говоря, управления конфигурацией в железках никакого, а когда они ещё и ломаться начинают, это только наполовину головная боль хостера.
По чипкору я так понимаю это тот же селектел, но ограничены методы оплаты и конфигурации на десктопных процах (еще меньше трафика, чем в обычном Селектеле), не думаю, что там есть какая-то разница в уровне услуг…
Если сами не пробовали, то как пытаетесь оценивать?:) Это такой же селектел, как и vscale. По факту, отдельная организация в рамках холдинга. Железо совершенно другое и по назначению и по стабильности, команда поддержки совершенно другая и спектр вопросов, которые они могут помочь вам решить мал просто до неприличия. По факту, зачастую ограничиваются исключительно перезагрузкой сервера в любой непонятной ситуации.
Могу ответить Metal-as-a-Service: maas.io
Виртуальные сервера это не всегда про то что дешевле.
Чаще всего в виртуальных серверах есть почасовой/поминутный билинг, снапшоты, миграции, блочные устройства и еще много разных плюшек за которые и приходится платить.
Большую часть из этого можно и на железе самому сделать. Но это уже затраты тех же денег или времени.
Чаще всего в виртуальных серверах есть почасовой/поминутный билинг, снапшоты, миграции, блочные устройства и еще много разных плюшек за которые и приходится платить.
Большую часть из этого можно и на железе самому сделать. Но это уже затраты тех же денег или времени.
UFO just landed and posted this here
Ну, я с вами не соглашусь. Бывают ситуации, когда свое железо дешевле конечно, но это от кейса к кейсу.
Могу вам озвучить реальную стоимость одной инфраструктуры в GKE, обслуживающей достаточно крупную команду заработки (частный бизнес, никаких бюджетов), состоящей из вот чего:
1. Два независимых K8s кластера, каждому по балансеру для Ingress. На обоих активно используются preemptible-ноды,:
— Один — 3 машины, в сумме 5 CPU и 14 Гб памяти в статике, иногда надувается до 11 CPU и около 30 Гб памяти.
— Второй — 9 машин, в сумме 9 CPU и 34 ГБ памяти в статике, надувается в пике до 30 CPU и почти 100 ГБ памяти (больше разрешено, но ни разу не видел).
2. 12 назависимых, но мелких PostgreSQL баз, в которых лежат всякие не очень критичные штуки, поэтому без включенного HA.
3. Еще одна достаточно база PostgreSQL, тоже мелкая, но с включенным HA.
4. Около 3.2 ТБ архивов в cold storage.
5. Около 500 Гб в региональном сторадже, куда кладутся первичные бэкапы, где живет Docker Registry и еще всяких штук по мелочи.
По обслуживанию — всегда последние security патчи без даунтайма и даже без просадки производительности, полностью автоматизированное управление.
Профит — нулевая очередь на сборку при любых нагрузках, максимальное ожидание — 3-4 минуты, пока автоскейл ноду инициализирует, все данные удобно бэкапятся, можно выключать\менять размер любых нод в течении 15 минут, убирать-добавлять сервисы по желанию вот прям тогда, когда нужно, ресурсы аллоцируются автоматически (ну то есть вообще нет вопроса «ой, какой то ресурс заканчиваеся»), сервисы изолированы друг от друга(сеть + физически разнесены на разные инстансы самые критичные штуки), можно при желании выдавать права на управление-администрирование (не в панельку, а вот прям внутрь) с градацией до сервиса, все легко переподнимается в любом другом месте в течении пары часов, т.к k8s + helm + дампы баз + где надо дампы статики с диска.
На обслуживание именно инфраструктуры тратится 30 минут в месяц, когда надо ткнуть апдейт для тех групп машин, для которых автоапдейт запрещен да кубик на мастерах обновить.
Обходится это все добро по данным биллинга в 650-700 долларов в месяц в зависимости от активности разработчиков.
И да, админа на окладе тут нет, потому что для этого он не нужен.
Да, за эти деньги можно взять 3 жирных машинки где-то в приличном месте, но обслуживание их будет стоить далеко не 100 баксов в пересчете на все простои, тупняки и зарплату специалистов.
Могу вам озвучить реальную стоимость одной инфраструктуры в GKE, обслуживающей достаточно крупную команду заработки (частный бизнес, никаких бюджетов), состоящей из вот чего:
1. Два независимых K8s кластера, каждому по балансеру для Ingress. На обоих активно используются preemptible-ноды,:
— Один — 3 машины, в сумме 5 CPU и 14 Гб памяти в статике, иногда надувается до 11 CPU и около 30 Гб памяти.
— Второй — 9 машин, в сумме 9 CPU и 34 ГБ памяти в статике, надувается в пике до 30 CPU и почти 100 ГБ памяти (больше разрешено, но ни разу не видел).
2. 12 назависимых, но мелких PostgreSQL баз, в которых лежат всякие не очень критичные штуки, поэтому без включенного HA.
3. Еще одна достаточно база PostgreSQL, тоже мелкая, но с включенным HA.
4. Около 3.2 ТБ архивов в cold storage.
5. Около 500 Гб в региональном сторадже, куда кладутся первичные бэкапы, где живет Docker Registry и еще всяких штук по мелочи.
По обслуживанию — всегда последние security патчи без даунтайма и даже без просадки производительности, полностью автоматизированное управление.
Профит — нулевая очередь на сборку при любых нагрузках, максимальное ожидание — 3-4 минуты, пока автоскейл ноду инициализирует, все данные удобно бэкапятся, можно выключать\менять размер любых нод в течении 15 минут, убирать-добавлять сервисы по желанию вот прям тогда, когда нужно, ресурсы аллоцируются автоматически (ну то есть вообще нет вопроса «ой, какой то ресурс заканчиваеся»), сервисы изолированы друг от друга(сеть + физически разнесены на разные инстансы самые критичные штуки), можно при желании выдавать права на управление-администрирование (не в панельку, а вот прям внутрь) с градацией до сервиса, все легко переподнимается в любом другом месте в течении пары часов, т.к k8s + helm + дампы баз + где надо дампы статики с диска.
На обслуживание именно инфраструктуры тратится 30 минут в месяц, когда надо ткнуть апдейт для тех групп машин, для которых автоапдейт запрещен да кубик на мастерах обновить.
Обходится это все добро по данным биллинга в 650-700 долларов в месяц в зависимости от активности разработчиков.
И да, админа на окладе тут нет, потому что для этого он не нужен.
Да, за эти деньги можно взять 3 жирных машинки где-то в приличном месте, но обслуживание их будет стоить далеко не 100 баксов в пересчете на все простои, тупняки и зарплату специалистов.
Более того, виртуальные сервера ВСЕГДА дороже ) В пересчете на производительность. Виртуалки хороши в двух случаях:
1. Вам нужно значительно меньше, чем один физический сервер (и нет смысла переплачивать).
2. Вам не очень важна разница в цене и важнее удобство администрирования и меньше косты на поддержку
Если же нужен большой объем, то точно выгоднее железо. Я например арендую десяток серверов, поверх которых развернуто примитивное private cloud, которое уже нарезано виртуалками удобным способом под разные проекты и задачи. Я думаю, получается раза в 3 дешевле, чем если бы я виртуалки брал.
1. Вам нужно значительно меньше, чем один физический сервер (и нет смысла переплачивать).
2. Вам не очень важна разница в цене и важнее удобство администрирования и меньше косты на поддержку
Если же нужен большой объем, то точно выгоднее железо. Я например арендую десяток серверов, поверх которых развернуто примитивное private cloud, которое уже нарезано виртуалками удобным способом под разные проекты и задачи. Я думаю, получается раза в 3 дешевле, чем если бы я виртуалки брал.
Ну, всегда есть три категории пользователей. Или больше.
1. стартап. Вкладываться в свое железо не выгодно, выгодно платить по схеме pay as you go. Виртуалки.
2. средний бизнес — пока еще до скидок в амазоне не дорос, но уже может позволить себе своих технарей. Можно использовать как облако (дорого), так и баре метал (стоимость железа по сравнению с ФОТ копейки, хотя и труд, считай, что дармовой).
3. большой бизнес — может прогибать поставщиков под выгодные условия. Вертит такими масштабами, что ему нужна возможность срочно аллоцировать ресурсы. Выгодный сценарий — или облако, или гибрид.
1. стартап. Вкладываться в свое железо не выгодно, выгодно платить по схеме pay as you go. Виртуалки.
2. средний бизнес — пока еще до скидок в амазоне не дорос, но уже может позволить себе своих технарей. Можно использовать как облако (дорого), так и баре метал (стоимость железа по сравнению с ФОТ копейки, хотя и труд, считай, что дармовой).
3. большой бизнес — может прогибать поставщиков под выгодные условия. Вертит такими масштабами, что ему нужна возможность срочно аллоцировать ресурсы. Выгодный сценарий — или облако, или гибрид.
Ещё мой случай опишу, который вроде как малый бизнес.
— Нет своего админа, который занимался бы серверами, мои возможности поддерживать и масштабировать собственные сервера ограничены. Как пример, 5 лет назад брал железку, ещё без SSD, теперь не знаю куда её девать, так как скорость работы дисков уже не удовлетворяет, а замена дисков например на тот же SSD — знатный геморрой.
— Растёт число клиентов, а следовательно постоянно требуется больше ресурсов. Отмасштабировать имеющиеся виртуалки можно вообще мгновенно, по API, добавить новую виртуалку — пара кликов. Наверное арендовать железки с ресурсами про запас было бы дешевле, но собственные железки сложнее нарезать на виртуалки, можно просто не угадать с пропорциями.
Плюс часть задач по обеспечению аптайма всё-таки перекидывается на хостера. Хотя с Selectel был негативный опыт: у них осенью было 2 подряд сбоя дисков, когда виртуалки лежали сперва около 12 часов, а затем и вообще около 30 часов.
Но всё равно простота и незаморочность при ограниченном количестве ресурсов на поддержку инфраструктуры подкупает.
— Нет своего админа, который занимался бы серверами, мои возможности поддерживать и масштабировать собственные сервера ограничены. Как пример, 5 лет назад брал железку, ещё без SSD, теперь не знаю куда её девать, так как скорость работы дисков уже не удовлетворяет, а замена дисков например на тот же SSD — знатный геморрой.
— Растёт число клиентов, а следовательно постоянно требуется больше ресурсов. Отмасштабировать имеющиеся виртуалки можно вообще мгновенно, по API, добавить новую виртуалку — пара кликов. Наверное арендовать железки с ресурсами про запас было бы дешевле, но собственные железки сложнее нарезать на виртуалки, можно просто не угадать с пропорциями.
Плюс часть задач по обеспечению аптайма всё-таки перекидывается на хостера. Хотя с Selectel был негативный опыт: у них осенью было 2 подряд сбоя дисков, когда виртуалки лежали сперва около 12 часов, а затем и вообще около 30 часов.
Но всё равно простота и незаморочность при ограниченном количестве ресурсов на поддержку инфраструктуры подкупает.
UFO just landed and posted this here
Вот вы говорите «спасет», а расскажите реальный кейс-более менее крупной инфраструктуры где она реально спасет, с учетом всех накладных расходов?
Я с облаками уже давно работаю и если учитывать не только прямые расходы, вроде стоимость ядра в месяц, то в большинстве (не во всех, но большинстве) сценариев облако выигрывает по совокупности и не особо то бьет по карману.
Я с облаками уже давно работаю и если учитывать не только прямые расходы, вроде стоимость ядра в месяц, то в большинстве (не во всех, но большинстве) сценариев облако выигрывает по совокупности и не особо то бьет по карману.
Добавить SSD в качестве кеша к существующим дискам и этого скорее всего будет достаточно.
UFO just landed and posted this here
Из результатов тестирования можно заключить, что наилучшие по быстродействию чтения SSD предлагает компания Servers — с результатами в 106 тысяч IOPS.
Хороший показатель на чтение с диска показывает SSD, предлагаемый компанией MCS, с показателем 23200 IOPS. Следующим идёт SSD Selectel со значением в 12800. И самый неудовлетворительный показатель у SSD, предоставляемом Я.Облаком: значение IOPS в 6228 совершенно никуда не годится :-( То же самое можно сказать про SSD Я.Облака в тесте не только на чтение с диска, но и на запись. Показатель очень мал — 2841/947. Лучше ситуация обстоит у SSD Mail, но тем не менее, результат тоже не особенно вдохновляет — 6152/2061 IOPS.
В этом тесте лидируют жесткие диски, использующиеся Selectel и Servers. Их показатели на чтение/запись — 12300/4122 и 8367/2799, соответственно.
Ничего не понял. У Servers 106000 iops или 8367?
Больший iops на практике означает, что на него нет лимитов, и человек с тяжелой виртуалкой может ухудшить жизнь соседям.
Вроде статью назвали «Нагрузочное тестирование», а по факту получилось «сравнение цен». Где хотя бы одна табличка с результатами измерения именно производительности?
Блин.
4 раза перечитал, так и не увидел сравнения производительности. Also, не увидел используемые цены на CPU, а у я.облака очень сильно по цене (и производительности) отличаются выделенные ядра и те, что с 5% гарантии.
4 раза перечитал, так и не увидел сравнения производительности. Also, не увидел используемые цены на CPU, а у я.облака очень сильно по цене (и производительности) отличаются выделенные ядра и те, что с 5% гарантии.
У меня еще вопрос — абсолютно за кадром остался момент какие именно ВМ тестировали в Яндексе. Там есть две категории — по гарантии на ресурсы. Я не очень понял, что это значит (что-то вроде спотовых инстансов у Амазона?), но явно, что это как минимум влияет на цену. А в худшем случае — еще и на быстродействие.
Sign up to leave a comment.
Нагрузочное тестирование CPU и SSD облачных хостеров: сравниваем Selectel, Servers, MCS и Я.Облако