Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Чего ж нельзя, можно.
Напедалить самому всегда можно. Другой вопрос — почему продукт, который пытаются представить последним достижением технологии, требует так много велосипедостроения.
НС>На локальном диске можно было меньше чем за неделю справится.
Остается только удивляться, куда пропадает весь софт, написанный такими форумными сверхчеловеками, и почему на рынке вместо него одно говно
Здравствуйте, Cyberax, Вы писали:
C>Storage accounts (или S3) достаточно тормозные, так как обеспечивают высокую надёжность хранения (овердофига девяток гарантии сохранности).
И отключить это конечно нельзя. Также, непонятно, почему это должно так сильно бить по производительности, особенно по чтению.
C>Но при этом они практически безгранично масштабируются горизонтально. Т.е. можно одновременно закачивать или скачивать десятки тысяч блобов, с суммарным потоком в терабиты в секунду (ничуть не преувеличение, я сам проверял).
И сколько ядер и оперативки для этого надо?
C>Для высокой скорости для одного потока нужно что-то другое. Или локальное хранилище, или блочное хранилище (EBS на AWS или Azure Managed Disks). Они имеют другие ограничения, по числу IOPS и пропускной способности.
А кто говорил про один поток? 120 мб/с — это для 16 потоков. А если поток один, то получаются совсем позорные 12 мб/сек.
C>Нет, просто не то выбираешь.
А выбора особо и нет. API у них вообще разный, просто так взять и заменить одно на другое нельзя, нужно перелопатить много кода.
Здравствуйте, Codealot, Вы писали:
C>>Storage accounts (или S3) достаточно тормозные, так как обеспечивают высокую надёжность хранения (овердофига девяток гарантии сохранности). C>И отключить это конечно нельзя. Также, непонятно, почему это должно так сильно бить по производительности, особенно по чтению.
Магии нет. В S3/SA данные попадают на физические серверы хранения, и при скачивании клиент подключается к тому серверу, который хранит данные. Эти серверы хранения имеют конечную пропускную способность, да ещё и разделяются между множеством потребителей услуг AWS.
Так что индивидуальная скорость потока получается ограниченной.
C>>Но при этом они практически безгранично масштабируются горизонтально. Т.е. можно одновременно закачивать или скачивать десятки тысяч блобов, с суммарным потоком в терабиты в секунду (ничуть не преувеличение, я сам проверял). C>И сколько ядер и оперативки для этого надо?
Нисколько. Серверная часть S3 работает на стороне AWS, клиентам пофиг как оно там внутри устроено.
C>>Для высокой скорости для одного потока нужно что-то другое. Или локальное хранилище, или блочное хранилище (EBS на AWS или Azure Managed Disks). Они имеют другие ограничения, по числу IOPS и пропускной способности. C>А кто говорил про один поток? 120 мб/с — это для 16 потоков. А если поток один, то получаются совсем позорные 12 мб/сек.
Значит кто-то пишет не так. Я легко получаю гигабайты в секунду с S3 на инстансе с 40Gb сетью, отдельные потоки — где-то 10-40 мегабайт в секунду. Оно скачивает быстрее, чем пишет на локальный диск, блин.
C>>Нет, просто не то выбираешь. C>А выбора особо и нет. API у них вообще разный, просто так взять и заменить одно на другое нельзя, нужно перелопатить много кода.
Managed Disks/EBS — это обычные диски.
Здравствуйте, Cyberax, Вы писали:
C>Магии нет. В S3/SA данные попадают на физические серверы хранения, и при скачивании клиент подключается к тому серверу, который хранит данные. Эти серверы хранения имеют конечную пропускную способность, да ещё и разделяются между множеством потребителей услуг AWS. C>Так что индивидуальная скорость потока получается ограниченной.
А кто им запрещал сделать локальную реплику? Раз уж всё равно данные распределены?
C>Нисколько. Серверная часть S3 работает на стороне AWS, клиентам пофиг как оно там внутри устроено.
Я имел в виду, сколько ядер и оперативки на клиенте?
C>>А кто говорил про один поток? 120 мб/с — это для 16 потоков. А если поток один, то получаются совсем позорные 12 мб/сек. C>отдельные потоки — где-то 10-40 мегабайт в секунду
Я ровно это и написал. Позорненькая скорость то.
Это сколько надо потоков, чтобы получился терабит?
C>Managed Disks/EBS — это обычные диски.
Тут в соседней ветке доказывали, что на самом деле это SAN и по другому никак нельзя делать.
Здравствуйте, Codealot, Вы писали:
C>Напедалить самому всегда можно. Другой вопрос — почему продукт, который пытаются представить последним достижением технологии, требует так много велосипедостроения.
Нет, это ты хочешь чего то, для чего продукт не предназначался.
НС>>На локальном диске можно было меньше чем за неделю справится. C>Остается только удивляться, куда пропадает весь софт, написанный такими форумными сверхчеловеками
Почему пропадает? Никуда не пропадает, успешно продается в составе большого продукта.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Нет, это ты хочешь чего то, для чего продукт не предназначался.
Этого хочу не я, а конечный потребитель.
Если вообще хоть немного подумать, то возможность выбрать между "супер-надежностью" и скоростью, раз уж нельзя иметь и то и другое — это очевидное требование к продукту.
Хотя, почему надежность так сильно бьет по скорости в этом случае, никто так и не смог внятно объяснить. RAID, например, позволяет не только улучшить надежность, но и повысить скорость. А не убить ее до скорости смертельно раненой улитки, как в облаке.
НС>Почему пропадает? Никуда не пропадает, успешно продается в составе большого продукта.
Да, говно — успешно продается, за неимением лучшего. А где нормальный продукт?
Здравствуйте, Cyberax, Вы писали:
C>>А выбора особо и нет. API у них вообще разный, просто так взять и заменить одно на другое нельзя, нужно перелопатить много кода. C>Managed Disks/EBS — это обычные диски.
У AWS есть разные "обычные диски" — EBS и Instance Storage. И то и другое выглядит на инстансе как обычный диск (блочное устройство).
EBS — это больше похоже на сетевой диск. Данные хранятся где-то на серверах AWS и передаются по сети. Данные сохраняются при переездах инстанса.
Instance Storage — данные хранятся на дисках, физически подключенные к серверу, на котором работает инстанс. Информация на них теряется при переездах.
Здравствуйте, Codealot, Вы писали:
C>Если вообще хоть немного подумать, то возможность выбрать между "супер-надежностью" и скоростью, раз уж нельзя иметь и то и другое — это очевидное требование к продукту.
Из трех вещей, надежность, скорость и цена, тебе придется выбрать две.
C>Хотя, почему надежность так сильно бьет по скорости в этом случае, никто так и не смог внятно объяснить.
Потому что надежность, даже LRS, предполагает размещение копий в разных стойках, а не на двух соседних дисках на одной шине. А GRS предполагает копии в разных регионах со всеми вытекающими.
C> RAID, например, позволяет не только улучшить надежность, но и повысить скорость.
RAID это не надежность, а профанация. Сдох контроллер — и привет вся твоя надежность.
НС>>Почему пропадает? Никуда не пропадает, успешно продается в составе большого продукта. C>Да, говно — успешно продается, за неимением лучшего.
Ну напиши лучше, делов то. Заработаешь несколько сотен миллионов баксов.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Из трех вещей, надежность, скорость и цена, тебе придется выбрать две.
Меня вполне устроит скорость и цена. Ну так что, как мне это сделать в Azure без необходимости велосипедить?
НС>Потому что надежность, даже LRS, предполагает размещение копий в разных стойках, а не на двух соседних дисках на одной шине. А GRS предполагает копии в разных регионах со всеми вытекающими.
Ну и читаем данные из ближайшей копии. В чем проблема?
НС>RAID это не надежность, а профанация. Сдох контроллер — и привет вся твоя надежность.
Облака — это не надежность, а профанация. Ложились подолгу уже все крупные облачные провайдеры.
НС>Ну напиши лучше, делов то. Заработаешь несколько сотен миллионов баксов.
- Представьте, шо ви в поле. Упереди вас араб. Ваши действия?
— Хватаю автомат и таки убиваю араба.
— Правильно. Следующая ситуация: ви в поле, впереди вас араб, слева и справа тоже по арабу. Ваши действия?
— Хватаю автомат и таки убиваю их всех.
— Правильно. Такая ситуация: ви в поле, перед вами три араба, сзади тоже три араба, справа/слева опять же по три араба, и еще танк едет. Ваши действия?
— Хватаю автомат и убиваю арабов. Потом бросаю гранату и подрываю танк.
— Правильно. А вот такая ситуация: ви в поле, впереди сотня арабов, справа/слева/сзади по сотне, три танка из-за холма показались и пяток вертолетов пикируют. Ваши действия?
— А можно вопрос?
— Можно.
— Я шо, один в израильской армии???
Здравствуйте, Codealot, Вы писали:
НС>>Из трех вещей, надежность, скорость и цена, тебе придется выбрать две. C>Меня вполне устроит скорость и цена.
Ну вот тогда premium это примерно максимум того, что можно получить в виде SaaS. Если и этого мало — придется развернуть свой CEF или MinIO на temp drives или UltraDisk.
НС>>Потому что надежность, даже LRS, предполагает размещение копий в разных стойках, а не на двух соседних дисках на одной шине. А GRS предполагает копии в разных регионах со всеми вытекающими. C>Ну и читаем данные из ближайшей копии. В чем проблема?
Ни в чем. Но гиг в секунду поверх HTTPS в этом случае вполне соответствует возможностям современного железа. Быстрее — это уже точно не про HTTPS.
НС>>RAID это не надежность, а профанация. Сдох контроллер — и привет вся твоя надежность. C>Облака — это не надежность, а профанация. Ложились подолгу уже все крупные облачные провайдеры.
Тут вопрос не бинарный, а вероятностный. Вероятность что у тебя в облаках накроются сразу несколько регионов и ты останешься без хранилища на несколько порядков ниже, чем вероятность того что у тебя единственный RAID контроллер гикнется, утянув потенциально за собой еще и диски с данными.
НС>>Ну напиши лучше, делов то. Заработаешь несколько сотен миллионов баксов.
C>- Я шо, один в израильской армии???
Получается что один, раз никому еще такая гениальная идея не пришла в голову.
Здравствуйте, Буравчик, Вы писали:
C>>Managed Disks/EBS — это обычные диски. Б>У AWS есть разные "обычные диски" — EBS и Instance Storage. И то и другое выглядит на инстансе как обычный диск (блочное устройство). Б>EBS — это больше похоже на сетевой диск. Данные хранятся где-то на серверах AWS и передаются по сети. Данные сохраняются при переездах инстанса. Б>Instance Storage — данные хранятся на дисках, физически подключенные к серверу, на котором работает инстанс. Информация на них теряется при переездах.
В Ажуре ровно тоже самое. Называется, соотв., managed disks и temp drive.
Здравствуйте, Codealot, Вы писали:
C>>Так что индивидуальная скорость потока получается ограниченной. C>А кто им запрещал сделать локальную реплику? Раз уж всё равно данные распределены?
S3 даёт гарантии целостности. Т.е. после записи в файл следующее чтение вернёт те же данные. Повторить такое локально невозможно, без фактического дублирования инфраструктуры S3.
C>>Нисколько. Серверная часть S3 работает на стороне AWS, клиентам пофиг как оно там внутри устроено. C>Я имел в виду, сколько ядер и оперативки на клиенте?
Я тестировал, по-моему, на c5n.2xlarge — 8 vCPU и 21Гб ОЗУ. Сам по себе код скачивания создаёт несущественную нагрузку.
C>>>А кто говорил про один поток? 120 мб/с — это для 16 потоков. А если поток один, то получаются совсем позорные 12 мб/сек. C>>отдельные потоки — где-то 10-40 мегабайт в секунду C>Я ровно это и написал. Позорненькая скорость то.
Почему? Более чем внушительно, учитывая все гарантии, которые даёт S3. Я имел счастье работать с локальными SAN, и такая производительность там была мечтой.
C>Это сколько надо потоков, чтобы получился терабит?
Ну так раздели сам. Несколько десятков тысяч (не на одной машине, понятное дело). Я вижу эти цифры в нашем мониторинге в пиковые часы для приложения. Сохраняемые данные — большие изображения (результат трассировки лучей с учётом позиции солнца для каждого светлого часа года).
C>>Managed Disks/EBS — это обычные диски. C>Тут в соседней ветке доказывали, что на самом деле это SAN и по другому никак нельзя делать.
Ну да. Это обычные диски (в RAID-е), доступные через SAN. Соответственно, они дают те же ограничения, что и любые другие диски — больше IOPS, больше полосы для отдельных запросов, но суммарная полоса ограничена железом.
Здравствуйте, Буравчик, Вы писали:
C>>>А выбора особо и нет. API у них вообще разный, просто так взять и заменить одно на другое нельзя, нужно перелопатить много кода. C>>Managed Disks/EBS — это обычные диски. Б>У AWS есть разные "обычные диски" — EBS и Instance Storage. И то и другое выглядит на инстансе как обычный диск (блочное устройство).
Ну да, я и называл Instance Store "локальным хранилищем".
Б>Добавлено: Б>Вот например тесты производительности. Хоть и старые, но соотношение, думаю, верное: Б>https://gist.github.com/ktheory/3c3616fca42a3716346b
Очень устарело. Вот немного более новое: https://www.scalebench.com/blog/index.php/2020/06/03/aws-ebs-vs-aws-instance-storelocal-disk-storage/
Здравствуйте, Cyberax, Вы писали:
C>S3 даёт гарантии целостности. Т.е. после записи в файл следующее чтение вернёт те же данные. Повторить такое локально невозможно, без фактического дублирования инфраструктуры S3.
Я имел в виду — реализацию у самого облачного провайдера. Почему они не могли сделать локальную реплику данных?
C>Я тестировал, по-моему, на c5n.2xlarge — 8 vCPU и 21Гб ОЗУ. Сам по себе код скачивания создаёт несущественную нагрузку. C>Ну так раздели сам. Несколько десятков тысяч (не на одной машине, понятное дело).
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Ну вот тогда premium это примерно максимум того, что можно получить в виде SaaS. Если и этого мало — придется развернуть свой CEF или MinIO на temp drives или UltraDisk.
Но поскольку API совершенно другой, то нужно велосипедить. То есть, без велосипедостроения совершенно элементарная задача у них не решается.
НС>Ни в чем. Но гиг в секунду поверх HTTPS в этом случае вполне соответствует возможностям современного железа. Быстрее — это уже точно не про HTTPS.
1) Не знаю, сам не проверял. А нафига тогда все эти 100-гигабитные эзернеты за очень много денег?
2) Кто запрещает сделать одну реплику данных прямо на том же хосте?
НС>Тут вопрос не бинарный, а вероятностный. Вероятность что у тебя в облаках накроются сразу несколько регионов и ты останешься без хранилища на несколько порядков ниже, чем вероятность того что у тебя единственный RAID контроллер гикнется, утянув потенциально за собой еще и диски с данными.
Никакие RAID контроллеры у меня никогда не гикались, а вот облачные провайдеры ложились все, и не по одному разу.
НС>Получается что один, раз никому еще такая гениальная идея не пришла в голову.
С чего ты решил, что нет?
Ну и ты вроде как сам писал, что делал велосипед ровно для этой задачи.
Здравствуйте, Codealot, Вы писали:
НС>>Ну вот тогда premium это примерно максимум того, что можно получить в виде SaaS. Если и этого мало — придется развернуть свой CEF или MinIO на temp drives или UltraDisk. C>Но поскольку API совершенно другой, то нужно велосипедить.
Нет, в случае premium базовый API тот же. А блочный API уже с поддержкой параллельного доступа с нескольких машин и атомарности апдейтов, что, сам понимаешь, скажется на перфомансе.
C> То есть, без велосипедостроения совершенно элементарная задача у них не решается.
Какая такая элементарная задача? Получение скорости локального диска на распределенном хранилище? Нет, это совсем не элементарная задача.
C> А нафига тогда все эти 100-гигабитные эзернеты за очень много денег?
А с чего ты взял что все упирается в эзернеты?
C>2) Кто запрещает сделать одну реплику данных прямо на том же хосте?
Это ты называешь элементарным решением? Ну ну.
Вообще, тебе, судя по всему, надо не решение, а поныть. Если тебе нужна скорость локального диска — бери MinIO, там есть режим кеширования на базе возможностей HTTP. Ставишь его сайдкаром в режиме кеша, в качестве volume используешь temp drive. Код писать не нужно, все готовое.
C>Никакие RAID контроллеры у меня никогда не гикались
У меня все работает? Ну ну.
НС>>Получается что один, раз никому еще такая гениальная идея не пришла в голову. C>С чего ты решил, что нет?
Ну если все как ты расписываешь — можно поднять много сотен гигабаксов, не?
C>Ну и ты вроде как сам писал, что делал велосипед ровно для этой задачи.
Я свой велосипед делал для строго ограниченных условий — запуск cloud native решения в условиях on prem. Универсального всемогутера как ты хочешь там нет.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Нет, в случае premium базовый API тот же. А блочный API уже с поддержкой параллельного доступа с нескольких машин и атомарности апдейтов, что, сам понимаешь, скажется на перфомансе.
Ну нет, не выкручивайся. Как мне получить "два из трех", о которых ты говорил, для системы, которая требует storage account API? И без велосипедостроения, естественно.
НС>А с чего ты взял что все упирается в эзернеты?
А вот что упирается?
НС>Это ты называешь элементарным решением? Ну ну.
А в чем проблема? Постарайся ответить внятно, а не ссылаться опять на какие-то неведомые сложности, которые слишком сложны, чтобы о них говорить.
НС>Вообще, тебе, судя по всему, надо не решение, а поныть.
Мне надо более быстрое хранилище, совместимое по API со storage account. Супер-большая надежность не требуется, достаточно обычной.
НС>У меня все работает? Ну ну.
Скажи ка мне, какова по твоему вероятность, что рейд-контроллер сломается?
НС>Ну если все как ты расписываешь — можно поднять много сотен гигабаксов, не?
Ты других вариантов кроме "не нужно никому" и "нужно всем" вообще не можешь себе представить?
Здравствуйте, Codealot, Вы писали:
НС>>Нет, в случае premium базовый API тот же. А блочный API уже с поддержкой параллельного доступа с нескольких машин и атомарности апдейтов, что, сам понимаешь, скажется на перфомансе. C>Ну нет, не выкручивайся.
Ты не подумал — зачем мне вообще выкручиваться? Я ничего не продаю. Хочешь разобраться — велкам, хочешь побрюзжать — на здоровье.
C> Как мне получить "два из трех", о которых ты говорил, для системы, которая требует storage account API? И без велосипедостроения, естественно.
Я тебе несколько решений предложил. Premium storage account, кластер MinIO, кластер CEF.
НС>>Это ты называешь элементарным решением? Ну ну. C>А в чем проблема?
В том что HTTP API предполагает работу по HTTP с его ограничениями и накладными расходами, и схему апдейта с поддержкой атомарности, что совсем не бесплатно.
C> Постарайся ответить внятно, а не ссылаться опять на какие-то неведомые сложности
Сложности вполне ведомые и задача на практике очень непростая. Хочешь досконально разобраться — попробуй сам реализовать поверх локального диска. Думаю, на этапе осознания необходимости распределенных блокировок ты многое начнешь понимать.
НС>>Вообще, тебе, судя по всему, надо не решение, а поныть. C>Мне надо более быстрое хранилище, совместимое по API со storage account.
Именно со storage account API — максимально это premium storage (гиг в секунду), все доступные альтернативные реализации медленнее. Если подойдет S3 API — вариантов больше.
НС>>У меня все работает? Ну ну. C>Скажи ка мне, какова по твоему вероятность, что рейд-контроллер сломается?
Если у тебя в кластере сотня дисков — очень высокая.
НС>>Ну если все как ты расписываешь — можно поднять много сотен гигабаксов, не? C>Ты других вариантов кроме "не нужно никому" и "нужно всем" вообще не можешь себе представить?
Здравствуйте, Codealot, Вы писали:
C>>S3 даёт гарантии целостности. Т.е. после записи в файл следующее чтение вернёт те же данные. Повторить такое локально невозможно, без фактического дублирования инфраструктуры S3. C>Я имел в виду — реализацию у самого облачного провайдера. Почему они не могли сделать локальную реплику данных?
Где "локальную"? Все запросы идут через один URL, который скрыт за тонной балансировщиков нагрузки.
C>>Я тестировал, по-моему, на c5n.2xlarge — 8 vCPU и 21Гб ОЗУ. Сам по себе код скачивания создаёт несущественную нагрузку. C>>Ну так раздели сам. Несколько десятков тысяч (не на одной машине, понятное дело). C>Что-то у тебя показания не сходятся
То есть? Это два разных теста — пропускная способность одной машины и пропускная способность одного bucket'а.
Ты хотел сказать Ceph или это что-то другое? Оба несовместимы по API, нужно велосипедить.
НС>В том что HTTP API предполагает работу по HTTP с его ограничениями и накладными расходами, и схему апдейта с поддержкой атомарности, что совсем не бесплатно.
Что мешало сделать не-HTTP API?
НС>Сложности вполне ведомые и задача на практике очень непростая. Хочешь досконально разобраться — попробуй сам реализовать поверх локального диска. Думаю, на этапе осознания необходимости распределенных блокировок ты многое начнешь понимать.
А кто сказал, что они нужны? В данном случае — данные читаются и меняются только в одной реплике. Которую в теории можно создать локально, на том же сервере. Остальные реплики обновляются асинхронно или вообще не нужны, потому что сверх-надежность здесь не нужна.
НС>Именно со storage account API — максимально это premium storage (гиг в секунду), все доступные альтернативные реализации медленнее. Если подойдет S3 API — вариантов больше.
Точно гиг? Throughput per Disk — P30 — 200 MB/sec
НС>Предлагай
Нунжно какой-то части пользователей. Причем многие из них даже не осознают свою проблему.
