Pull to refresh

Comments 40

Слышал, что у гугла цены ниже только на бумаге, а в жизни тоже с сюрпризом, как и ядра. Azure кроме всего прочего идеален для разведения телеграм-ботов — бесплатно и хттпс искаропки. И публикация прямо из студии, красота.
AWS тоже любит подводные камни и скрытые счета. За трафик, быстрые диски и т.п.
Azure кроме всего прочего идеален для разведения телеграм-ботов — бесплатно и хттпс искаропки.


Для того чтобы что-то запускать условно бесплатно лучше всего вам подойдет PaaS. Все же если пишете бота или простой бекенд request/response узнайте про AppEngine, например c Go runtime cloud.google.com/appengine/pricing и да вы получите https://*.appspot.com бесплатно.
Или если IaaS все же — AWS Free Tier instance micro, но читайте условия.
С Google, кстати, есть еще одна «засада». Уже после тестов, разбирая скриншоты, стало ясно, что инстансы от Azure и AWS у меня были расположены в Европе, а Google — в Штатах. Т.е. при поднятии сервера я не обратил внимание на регион. А тонкость тут в том, что изменить местоположение дата-центра при поднятии сервера нельзя. Делается это в общих настройках консоли всех виртуальных машин, что не совсем очевидно.

На вашем же скриншоте:



Второй пункт — зона.

Да тут вообще какое-то странное сравнение.
Тем не менее, думается, что еще два ядра от изменения географии дата-центра вряд ли появятся.

Автор сам пишет про виртуальные ядра, сам недоумевает. И таки да, от географии зависит железо.
Ну а цена на Azure формально самая высокая (~$356). Однако она не сильно отличается от AWS. А если учесть, что при регистрации в Azure мы получаем бонусные $200, так и вовсе становится средней.

А про 300$ у гугла — вообще ни слова.
Из таблицы по вашей ссылке видно, что разница есть, но минимальная. И она не дает ответа на вопрос, гипертрединговые ядра там раздают или реальные
В данном месте можно было выбрать только между тремя дата-центрами, расположенными в Штатах. Чтобы сменить регион, надо было лезть в пункт «настройки». Его видно в меню слева. И тогда там появились бы дата-центры соответствующего региона.
Вообще все эти облака от лукавого, тоже что и VPS только на уровень ниже.
Т.о. получив чего-то там виртуального вы будете платить реальное. И платите вы не за реальное быстродействие, кое может для вас менятся в разы с течением времени, а за мифические 2 core and m4.xlarge.
Т.о. облака стоило также сравнить по степени загрузки. Может оказаться что Azure не так популярен, соотвественно и простаивающих мощностей там побольше.

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

Во время тестирования столкнулся с тем что AWS тачка с 32 ядрами + 64 Гбайтами памяти была в разы медленнее чем моя домашняя тачка с 4 процами и 8 Гб памяти. После этого в облака я перестал верить.
Облака в первую очередь — это не только инстансы, но набор сервисов которые предоставляет поставщик услуг.
Для начала посмотрите список сервисов которые предлагает тот же AWS/GCP/Azure

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

SLA в три, четыри девятки

https://azure.microsoft.com/en-us/support/legal/sla/virtual-machines/v1_6/
•For all Virtual Machines that have two or more instances deployed in the same Availability Set, we guarantee you will have Virtual Machine Connectivity to at least one instance at least 99.95% of the time.
•For any Single Instance Virtual Machine using premium storage for all Operating System Disks and Data Disks, we guarantee you will have Virtual Machine Connectivity of at least 99.9%.
Уже после заливки материала на Хабр увидел вот эту статью. Ну, значит, все действительно так и есть.

Ведь парень с подписью Azure MVP никогда не будет предвзят, верно?)


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

Кажется, тестировали одинаковые инстансы, просто в разных регионах. Но производительность от этого не сильно изменится.

Я лично ориентировался на вычислительные нагрузки и брал то, что наиболее соответствовало им. У AWS это EC2, у остальных универсальные «standard». Да, с инстансами там везде можно долго играться (вариантов много и без поллитра с ними не разберешься), но подсовывать гипертрединговые ядра в самых популярных нигде не упоминая про это — это как то совсем некрасиво
Ну извините, денег мне Майкрософт не платит за эти статьи :) А врать как-то…

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


Возможно, я тоже предвзят и вижу лычку и из-за нее наговариваю на вас)

Я писал в статье что я специально никаких «приемчиков» не использовал, а просто создавал виртуальные машины с портала используя далее-далее-далее (только выбирал размер и ссд). Если в АВС или Гоогле можно как-то оптимальнее создать ВМ я этого не знаю, но это не должно быть важно, ибо я сравнивал «значения по умолчанию»
Спасибо за статью!!! Буду юзать Azure… для меня выходит выгоднее аналогов)
А какова архитектура системы например у Azure?
Имеется мощный сервер на нем гипервизор а в нем виртуалка с выбранным железом?
Просто
Ну а цена на Azure формально самая высокая (~$356)

как то высоковато. Если это не выделенный сервер.
Просто смотрю этого хостера ua-hosting.company (не реклама просто для примера)
у него выделенные серваки есть за 300$ в месяц.
Можете объяснить чем отличается хостинг виртуалки на Azure и ua-hosting.company
просто не понятно почему такая разница в цене? Или это кардинально разные сервисы?

Всё зависит от задач. Если вам просто один инстанс. То лучше выделенный сервер. Если отказоустойчивая архитектура — то AWS/Axure и так далее будут проще. Например, подключаете RDS на амазоне — и у вас есть отказоустойчивая база данных. S3 — для хранилища файлов с версионингом.

Самые дешёвые сервера на hetzner.de, ovh.ie (хотя на ovh — когда мы попробовали взять 10 серверов — некоторые из них периодически вываливались из сети, глючили и т.п.). Сервер на hetzner за 50 долларов уделает AWS инстанс за 500.
UFO just landed and posted this here

Админа будет откровенно маловато. Вам нужен будет целый отдел админов.


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


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


Так что тут еще вопрос, что дешевле получится в итоге.

UFO just landed and posted this here
Судя по всему, у вас практически нет представлений о том, что такое облако, отказоустойчивость, маштабирование, etc которые предоставляет AWS/GCP/Azure
что за зион такой на 4.7 ггц?
К примеру, при выборе многоядерных систем тот же Гугл оперирует значениями неких виртуальных ЦП, нигде не поясняя, что это значит.

В документации это описано. Не знаю, где вы смотрели.
What is a virtual CPU in Google Compute Engine?
For the n1 series of machine types, a virtual CPU is implemented as a single hardware hyper-thread on a 2.6 GHz Intel Xeon E5 (Sandy Bridge), 2.5 GHz Intel Xeon E5 v2 (Ivy Bridge), 2.3 GHz Intel Xeon E5 v3 (Haswell), 2.2 GHz Intel Xeon E5 v4 (Broadwell), or 2.0 GHz Intel (Skylake) platform...

AWS
Each vCPU is a hyperthread of an Intel Xeon core except for T2 and m3.medium.
*M3 instances may also launch on an Intel Xeon E5-2670 (Sandy Bridge) Processor running at 2.6 GHz.
** These M4 instances may launch on an Intel Xeon E5-2686 v4 (Broadwell) Processor.


Как бы тест изначально неверный, поскольку выбраны неравные конфигурации.

Нормально зарегистрироваться с первого раза получилось только с Azure. Google по каким-то причинам отказался принимать банковскую карту, заявив о «недопустимом способе оплаты» — хотя и Amazon и Azure восприняли карту нормально.

GCP не принимает prepaid-карты и одну карту можно привязать только к одному аккаунту.
Про бонус GCP, как уже писалось, вы забыли. AWS дает на год бесплатное время, правда на самом дешевом инстансе.
Ну и как-бы учитывая выбранную вами конфигурацию, и то, что обычно идет не один сервер, а — больше. Бонусы в сравнении цены можно не учитывать.

Тест поверхностный и мягко говоря некорректный. И весь Azure у вас вышел таким лазурным, как берег в Ницце, а GCP и AWS как пляж в Крыму — дорого и грязно.

Тесты дисковой подсистемы несколько некорректны. Фокус в том, что у AWS системный диск — это всегда EBS, т.е. сетевой диск. И на него бывают разные ограничения (можно разные квоты поставить), он бывает старый, а бывает и новый SSD-based… Нет, старые машины ещё доступны и иногда в них действительно есть смысл.
Начал писать и прям дежавю словил — три года назад точно также расписывал разницу между сетевыми дисками в aws/azure.

Автор статейки видимо не в курсе или умолчал за Спотовые инстансы Amazon EC2.
Применяя спотовые инстансы, вы можете сократить свои эксплуатационные расходы на 50–90% по сравнению с использованием инстансов по требованию.

Небольшая ремарка: чтобы вашу spot-цену не перебили выбирайте зону с наименьшими скачками цены.

А теперь покажите мне в азурах и гуглах что-то напоминающее спотовые цены :)

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

Для меня не понятно с каких пор эталоном тестирования дисковой подсистемы стала утилита CrystalDiskMark? При том что ей разве только обычные USB-флешки тестировать можно. Документация по утилите совершенно скудная.


Режим прямого ввода/вывода, с обходом кэширования на уровне OS не включается. Нет возможности создать большой тестовый файл (в несколько раз больше ОЗУ), что бы нивелировать эту проблему. Т.е. не понятно, что протестировали. То ли ОЗУ компьютера, то ли погоду за окном.


Идем дальше. Вы когда-нибудь видели сервер (или HDD) работающий только в режиме записи или только в режиме чтения и при этом в один поток I/O? Или считаете, что эти операции никак на друг друга не влияют и все приложения пишут и читают в один поток? Так какой смысл тестировать дисковую подсистему в условиях, в которых она никогда работать не будет даже в теории? Не лучше ли создавать смешанный поток I/O с известным соотношением чтение/запись, что намного ближе к реальной работе сервера и его дисковой подсистемы? А вот это как раз CrystalDiskMark делать не умеет.


Ну и совсем уж простое. Объясните мне (аргументированно с отсылкой к документации) какие значения показывает CrystalDiskMark в результате? Средние полученные в процессе теста? Или максимальный пик, полученный в какую то долю секунды в процессе теста? И на какие стабильные, в течении длительного времени, значения по количеству операций ввода/вывода (IOPS) я могу рассчитывать например при использовании MSSQL на протестированных вами облачных VM?


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


P.s. P.s. В приведенной вами аналогичной статье все тот же CrystalDiskMark, так что вы не одиноки.

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

Поясните, что имели в виду про кэширование — для ВМ и дисков данных есть рычаг для того, чтобы ковырять кэширование.

Вы вырвали одну фразу из контекста и попытались найти ответ на нее. :)
Про тюнинг DB это все понятно. Главный вопрос был:


Почему CrystalDiskMark стал считается утилитой для тестирования дисковой подсистемы серверов?


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


Если мы хотим понять, что в принципе может дисковая подсистема, то нужно использовать тесты, которые умеют выполнять Direct I/O избегая попадания данных в кеш OS (как пример fio). Либо умеют создавать тестовый файл, превышающий своим размером в несколько раз ОЗУ тестируемой системы, опять же что бы система не смогла закэшировать данные и отдавать их просто из ОЗУ, не обращаясь к дисковой подсистеме (пример: IOMETER или тот же fio). Ни того ни другого CrystalDiskMark не умеет и уж темболее не умеет создавать смешанную нагрузку с одновременным чтением и записью данных.


Кроме того, что бы реально нагрузить дисковую подсистему и посмотреть максимум того, что она может, не достаточно использовать всего один поток ввода/вывода. Он упрется либо в возможности самого теста по генерации нагрузки, либо в ограничения OS для одного потока I/O. Нормальные тесты умеют работать с несколькими (в т.ч. десятками и сотнями) потоков I/O.

Все так. Я использовал конкретную фразу, поскольку для меня все подобные тесты должны приводить к одному — к решению о том, хватит ли попугаев для моего сервиса или нет. Если это MSSQL, то для него уже эту задачу частично решили разными способами. Если что-то кастомное, то исследование в статье можно использовать как отправную точку, а дальше уже ковырять в сторону того, что вы написали.
Было бы классно увидеть что-то по этой теме. У вас есть материалы/методики?

Могу дать ссылки на статьи на Habr-е с чего начать.


https://habrahabr.ru/post/154235/
https://geektimes.ru/post/78632/
https://habrahabr.ru/post/245859/
https://habrahabr.ru/post/168711/


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


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

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

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

UFO just landed and posted this here
Судя по скриншоту, автор гонял GCP на Haswell, хотя мог взять Skylake — на два поколения новей.
И до Local SSD, видимо, маны тоже не дочитал https://cloud.google.com/compute/docs/disks/local-ssd

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

Sign up to leave a comment.

Articles