Здравствуйте, Codealot, Вы писали:
НС>>Нет, все упирается в то, сколько ты заплатил. Платишь за P80 и получаешь гигабайт в секунду. C>Всего лишь? Даже недорогой SSD может в разы больше.
Это NAS, при чем тут локальный SSD? Локальный диск у тебя в temp drive.
Здравствуйте, Codealot, Вы писали:
C>Azure Managed Disks are high-performance, durable block storage designed to be used with Azure Virtual Machines and Azure VMware Solution. C>Ну и в каком месте это NAS?
В прямом. Это диск, который можно подключать к любым VM. Физически это классический NAS. А физический диск в ажуре это temp drive, который при сбое или переезде ВМ будет весь протерян.
C>2) если современные диски намного быстрее и сеть тоже, то почему storage account такой медленный?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>В прямом. Это диск, который можно подключать к любым VM. Физически это классический NAS. А физический диск в ажуре это temp drive, который при сбое или переезде ВМ будет весь протерян.
Ну это странно, потому что для этой задачи делать его как NAS смысла очень мало. storage account — там еще понятно, зачем.
НС>Потому что это NAS, а не локальный диск.
Здравствуйте, Codealot, Вы писали:
C>Ну это странно, потому что для этой задачи делать его как NAS смысла очень мало.
Там не то что смысла много, это обязательное требование. Потому что иначе, когда твоя ВМ уйдет на обслуживание или накроется вместе с диском, ты весь диск потеряешь. А так системный диск просто подключается к другой живой ВМ.
НС>>Потому что это NAS, а не локальный диск. C>Даже для NAS он тормозит совершенно неприлично.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Там не то что смысла много, это обязательное требование. Потому что иначе, когда твоя ВМ уйдет на обслуживание или накроется вместе с диском, ты весь диск потеряешь. А так системный диск просто подключается к другой живой ВМ.
Постоянный бэкап, если что случилось — скопировал на новый узел и запустил ВМку. Зачем там делать NAS?
НС>1 гиг в секунду это тормозит?
Я про storage account, если ты не заметил. И про реальную скорость, а не "до 100500 гиг в секунду. И пусть кто попробует сказать, что 1 мегабайт — это не до 100500 гиг."
Но и гиг в секунду, для современного железа — тоже не особо.
storage account и managed disk, про который ты толкуешь — разные вещи.
НС>Ну так померяй реальную, раз не веришь.
Именно это я и сделал, о чем с самого начала и написал.
А ты видимо чукча-писатель?
НС>Что ты понимаешь под современным железом и насколько ему соответствует то железо, на котором работает тво ВМ?
Обычное, даже не самое навороченное.
А ВМ — точнее, хранилище данных — не мое, а мелко-мягких. Они же софт для хранилища данных делали, не я.
Здравствуйте, Codealot, Вы писали:
C>Ну это странно, потому что для этой задачи делать его как NAS смысла очень мало.
Оно там скорее не NAS а SAN
И да, именно так и надо делать.
Видимо все же ты. Потому что ты явно померял standard, который ограничен совсем не железом.
НС>>Что ты понимаешь под современным железом и насколько ему соответствует то железо, на котором работает тво ВМ? C>Обычное, даже не самое навороченное.
Оно там вполне конкретное и вполне понятно какое. Оно для тебя достаточно современно?
Здравствуйте, Codealot, Вы писали:
C>Чтобы более лучше тормозило?
Я не пойму что тебя не устраивает? Нравится периодически терять данные — пиши на temp drive, его у тебя никто не отбирает. Хочешь чтобы данные жили дольше чем ВМ — придется использовать внешнее хранилище. Хочешь чтобы это хранилище было дешевым — мирись с определенными тормозами.
Отвечая на твой исходный вопрос — да, это нормально, по определению. У обоих основных поставщиков облачных решений ситуация в этом плане примерно одинаковая (и у Azure, кстати, топовый tier (Ultra disks, 2Гб/с. Через storage api, емнип, недоступно по понятным причинам) заметно быстрее топового S3, это на сейчас самое быстрое решение на рынке).
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Видимо все же ты. Потому что ты явно померял standard, который ограничен совсем не железом.
Default maximum egress for general-purpose v2 and Blob storage accounts
120 Gbps
А теперь расскажи мне, как из этого числа получается 60 мегабайт в секунду.
НС>Оно там вполне конкретное и вполне понятно какое. Оно для тебя достаточно современно?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Я не пойму что тебя не устраивает? Нравится периодически терять данные — пиши на temp drive, его у тебя никто не отбирает.
А что, репликацию данных они не умеют?
Но на самом деле, меня даже сохранность данных не особо волнует. Это всего лишь аналитика, которая нужна только пока обрабатывается. Но. Система сделана так, что там нужен именно storage account, потому что там используется Synapse и прочий говно-data-science, который завязан на конкретно этот API. А просто так взять и создать локальное хранилище с тем же API, я так понимаю, нельзя. Это было бы слишком просто
НС>Хочешь чтобы данные жили дольше чем ВМ — придется использовать внешнее хранилище. Хочешь чтобы это хранилище было дешевым — мирись с определенными тормозами.
Ты вообще всё в кучу смешал. Не нужен никакой SAN, чтобы данные не терялись с перезагрузкой ВМ. VirtualBox никогда не пользовался?
И никакая "дешевизна" (в кавычках, потому что оно вовсе не дешевое относительно стоимости самого железа) не оправдывает такую днищенскую производительность.
Здравствуйте, Codealot, Вы писали:
C>Ты вообще всё в кучу смешал. Не нужен никакой SAN, чтобы данные не терялись с перезагрузкой ВМ. VirtualBox никогда не пользовался?
Здравствуйте, CreatorCray, Вы писали:
C>>Ты вообще всё в кучу смешал. Не нужен никакой SAN, чтобы данные не терялись с перезагрузкой ВМ. VirtualBox никогда не пользовался? CC>
Здравствуйте, Codealot, Вы писали:
НС>>Видимо все же ты. Потому что ты явно померял standard, который ограничен совсем не железом. C>Default maximum egress for general-purpose v2 and Blob storage accounts C>120 Gbps C>А теперь расскажи мне, как из этого числа получается 60 мегабайт в секунду.
Storage accounts (или S3) достаточно тормозные, так как обеспечивают высокую надёжность хранения (овердофига девяток гарантии сохранности).
Но при этом они практически безгранично масштабируются горизонтально. Т.е. можно одновременно закачивать или скачивать десятки тысяч блобов, с суммарным потоком в терабиты в секунду (ничуть не преувеличение, я сам проверял).
Для высокой скорости для одного потока нужно что-то другое. Или локальное хранилище, или блочное хранилище (EBS на AWS или Azure Managed Disks). Они имеют другие ограничения, по числу IOPS и пропускной способности.
НС>>Оно там вполне конкретное и вполне понятно какое. Оно для тебя достаточно современно? C>Раз так тормозит — значит, недостаточно.
Нет, просто не то выбираешь.
Здравствуйте, Codealot, Вы писали:
C>А просто так взять и создать локальное хранилище с тем же API, я так понимаю, нельзя. Это было бы слишком просто
Чего ж нельзя, можно. У нас, емнип, на реализациею этого API поверх файловых шар ушло где то человекомесяц, причем большая часть была потрачена на войну с шарами. На локальном диске можно было меньше чем за неделю справится.
Если же именно ажурное API не принципиально и подойдет S3 — есть MinIO.
C>И никакая "дешевизна" (в кавычках, потому что оно вовсе не дешевое относительно стоимости самого железа) не оправдывает такую днищенскую производительность.
Здравствуйте, CreatorCray, Вы писали:
CC>Чувак, я занимался как раз storage для виртуализации, так что твои фантазии как оно должно быть кроме фейспалма ничего не вызывают.
Мне твое надувание щек еще меньше интересно. Если ты действительно чем-то там таким занимался, то у тебя не должно вызывать ни малейших проблем дать ясный и четкий ответ на мой вопрос.
