Господа, а правильно ли я понимаю, что в массе своей все енто стало доступно и бурно развивается благодря x64 и 64-битной адресации памяти? Т.е. при x32 енто в принцие невозможно,
ибо где на 4гб разгуляться? А тут ставишь себе под 200Гб и пару десятков ОС можно хостить. Какие еще железные факторы сделали такой рост возможным -- ssd, рост сетевой пропускной
способности и т.д., т.е. уменьшение latency до вполне приемлемого уровня. Но в первую очередь, кмк, x64. Софт тут далеко вторичен, кмк.
Здравствуйте, Sharov, Вы писали:
S>Господа, а правильно ли я понимаю, что в массе своей все енто стало доступно и бурно развивается благодря x64 и 64-битной адресации памяти? Т.е. при x32 енто в принцие невозможно
Я думаю за счёт увелечния каналов свзяи, покрытия и скоростей в первую очередь.
Здравствуйте, Kernan, Вы писали:
S>>Господа, а правильно ли я понимаю, что в массе своей все енто стало доступно и бурно развивается благодря x64 и 64-битной адресации памяти? Т.е. при x32 енто в принцие невозможно K>Я думаю за счёт увелечния каналов свзяи, покрытия и скоростей в первую очередь.
Хорошо, а какой в ентом смысл, если у нас всюду 32 бита. Т.е. это равносильно просто покуке своего железа и установки в какой-нибудь датацентр, облако тут вообще не причем.
Все работает быстро, но мы привязаны к своему железу, никакой гибкости.
S>Хорошо, а какой в ентом смысл, если у нас всюду 32 бита.
Ну, допустим, 32 бита. 14-15 виртуалок с 256 мег оперативки (остальное на систему). 256 мег хватит для простейших нужд (веб-сайтик, vpn-сервер, малонагруженная база на мускуле).
А если помозговать над оптимизацией кода... но зачем мозговать если ресурсы дешевые? Даже в бюджетных мобилах уже 2 гига оперативки.
Здравствуйте, L.K., Вы писали:
S>>Хорошо, а какой в ентом смысл, если у нас всюду 32 бита.
LK>Ну, допустим, 32 бита. 14-15 виртуалок с 256 мег оперативки (остальное на систему). 256 мег хватит для простейших нужд (веб-сайтик, vpn-сервер, малонагруженная база на мускуле).
Ну т.е. ни о каких SAAS, PAAS и прочих *AAS говорить не приходится. Так, для персональных нужд машина.
Здравствуйте, Sharov, Вы писали:
LK>>Ну, допустим, 32 бита. 14-15 виртуалок с 256 мег оперативки (остальное на систему). 256 мег хватит для простейших нужд (веб-сайтик, vpn-сервер, малонагруженная база на мускуле).
S>Ну т.е. ни о каких SAAS, PAAS и прочих *AAS говорить не приходится. Так, для персональных нужд машина.
Вы наверное забыли, на каких машинах хостились типичные сайты нулевых. 256 — это хороший объём оперативы по тем временам, особенно в сравнении с shared-hosting.
С>Вы наверное забыли, на каких машинах хостились типичные сайты нулевых. 256 — это хороший объём оперативы по тем временам, особенно в сравнении с shared-hosting.
Но про айот, бигдату и какой-нибудь слак придется забыть.
Здравствуйте, Sharov, Вы писали:
С>>Вы наверное забыли, на каких машинах хостились типичные сайты нулевых. 256 — это хороший объём оперативы по тем временам, особенно в сравнении с shared-hosting. S>Но про айот, бигдату и какой-нибудь слак придется забыть.
IoT требует множества ждущих подключений с очень малым трафиков. Какой-нибудь IOCP-сервер начала нулевых без труда потянет 10 000 таких соединений. Вместо слака (слава богу) в те годы обходились аськой — и неплохо так получалось! Без ElectronJS и прочего ракообразия.
Про бигдату ничего сказать не могу, это удивительно мутный термин.
Здравствуйте, Sharov, Вы писали:
S>Господа, а правильно ли я понимаю, что в массе своей все енто стало доступно и бурно развивается благодря x64 и 64-битной адресации памяти? Т.е. при x32 енто в принцие невозможно,
Я полагаю, облака выстрелили за счет появления подходов к проектированую веб-серверного хозяйства, производительность которого практически линейно массштабируется путем добавления еще компьютеров в нужном количестве. Всякие там микросервисы, map-reduce, NoSQL и т.д. и т.п.
Это ведь очень круто, наваять на коленке с помощью node.js какую-то хрень за неделю, а когда вдруг выяснится, что она выстрелила и количество пользователей растет, как на дрожжах, не уходить на год в переписывание с учетом ставшими вдруг актуальными требованиями к производительности, а просто добавить серверов.
В серверах уже давно 64 бита. Гораздо раньше чем все эти облака стали популярными. Конечно с 32 битами особо не разгонишься по нынешним временам, но не думаю, что оно тут играет особое значение. Не было бы x86, были бы облака на Itanium/Sparc/Power/etc. Полно серьёзных архитектур было.
Здравствуйте, Sharov, Вы писали:
С>>Вы наверное забыли, на каких машинах хостились типичные сайты нулевых. 256 — это хороший объём оперативы по тем временам, особенно в сравнении с shared-hosting.
S>Но про айот, бигдату и какой-нибудь слак придется забыть.
На заре компьютерной цивилизации, во времена PDP/11 и 8080, программе редко когда выделялось больше нескольких десятков килобайт. При этом любой уважающий себя редактор текстов позволял редактировать файлы виртуально любого размера. Хотя слишком уж большие файлы редактировать было уныло из-за медленного дискового ввода/вывода, принципиального ограничения в редакторе на размер файла не было.
Сейчас же искусство писать программы, не способные засунуть в память разом все данные, с которыми они работают в настоящий момент, кажется, утрачено.
Я к тому, что кроме malloc(100500 гигабайт) есть и более другие способы управиться с большим объемом данныых.
Здравствуйте, Pzz, Вы писали:
Pzz>Я полагаю, облака выстрелили за счет появления подходов к проектированую веб-серверного хозяйства, производительность которого практически линейно массштабируется путем добавления еще компьютеров в нужном количестве. Всякие там микросервисы, map-reduce, NoSQL и т.д. и т.п.
Pzz>Это ведь очень круто, наваять на коленке с помощью node.js какую-то хрень за неделю, а когда вдруг выяснится, что она выстрелила и количество пользователей растет, как на дрожжах, не уходить на год в переписывание с учетом ставшими вдруг актуальными требованиями к производительности, а просто добавить серверов.
А вот енто крайне интересная точка зрения! Т.е. тот же map-reduce или CAP сдвинули дело с мертвой точки? Хотел было написать комментарий, что m-r был придуман для утилизации железа,
но ведь он по сути был изобретен для эксплуатации кучи слабого железа. Ок, тут согласен, и тут даже облака с боку. А вот возможность аренды ОС, т.е. не конечный сервис масштабировать,
а брать чистую ОС, причем в любых количествах, т.е. PAAS и ниже. Тут явно без x64 делать нечего.
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, Kernan, Вы писали:
S>>>Господа, а правильно ли я понимаю, что в массе своей все енто стало доступно и бурно развивается благодря x64 и 64-битной адресации памяти? Т.е. при x32 енто в принцие невозможно K>>Я думаю за счёт увелечния каналов свзяи, покрытия и скоростей в первую очередь.
S>Хорошо, а какой в ентом смысл, если у нас всюду 32 бита.
У меня всюду 64. Не знаю как у тебя там . S>Т.е. это равносильно просто покуке своего железа и установки в какой-нибудь датацентр, облако тут вообще не причем.
Не так. В облаке ты покупаешь надёжность и доступность. Не надо бэкапить, не надо админить. Запалтил деньги за гиги и наслаждаешься. Это удобно. Даже тот же Близзард отдал на хранение, хранение, Карл!, сорцы WoW Classic в другую компанию. S>Все работает быстро, но мы привязаны к своему железу, никакой гибкости.
Ну да, так и есть. Ещё железо может сломаться.
Здравствуйте, vsb, Вы писали:
vsb>В серверах уже давно 64 бита. Гораздо раньше чем все эти облака стали популярными. Конечно с 32 битами особо не разгонишься по нынешним временам, но не думаю, что оно тут играет особое значение. Не было бы x86, были бы облака на Itanium/Sparc/Power/etc. Полно серьёзных архитектур было.
Согласен, но проведем мысленный эксперимент -- допустим x64 физически невозможно(бред, но все же), люди могут только x32 и все-тут, вселенная такая и законы физики, ничего не поделаешь. В такой вселенной
возможны были бы облака?
Здравствуйте, Sharov, Вы писали:
S>А вот енто крайне интересная точка зрения! Т.е. тот же map-reduce или CAP сдвинули дело с мертвой точки? Хотел было написать комментарий, что m-r был придуман для утилизации железа,
Да, именно они. В сочетании с осознанием в индустрии того факта, что eventually consistent модель данных подходит для большинства решаемых задач ("ну, подумаешь, коммент потерялся. Пользователь еще напишет").
S>но ведь он по сути был изобретен для эксплуатации кучи слабого железа.
Ну правильно, появилась возможность держать большую нагрузку, обходясь умеренными расходами на аппаратуру.
S>а брать чистую ОС, причем в любых количествах, т.е. PAAS и ниже. Тут явно без x64 делать нечего.
64-битность ценна потому, что куча памяти состовляет лишь небольшую долю в цене компьютера. Будь память подороже, или вся прочая начинка подешевле, ценность 64-битности была бы очень нишевой — там, где действительно необходимо одновременно держать в памяти большой массив данных (некоторые виды физических рассчетов, например).
Здравствуйте, Pzz, Вы писали:
Pzz>64-битность ценна потому, что куча памяти состовляет лишь небольшую долю в цене компьютера. Будь память подороже, или вся прочая начинка подешевле, ценность 64-битности была бы очень нишевой — там, где действительно необходимо одновременно держать в памяти большой массив данных (некоторые виды физических рассчетов, например).
Как будете раздовать операционки в аренду, если у гипервизора самого 4гб всего?
Здравствуйте, Sharov, Вы писали:
S>Как будете раздовать операционки в аренду, если у гипервизора самого 4гб всего?
На машинке с 4гб поместится 7-8 виртуальных машинок, если каждой выдать по полгига. А поскольку существенную часть цены сервера составляет корпус с блоком питания, а так же место, которое вся эта конструкция занимает в корпусе, я могу себе представить серверный компьютер, в котором несколько процессоров, и у каждого своя личная память, а корпус, питальник и материнская плата — общие. Собственно, мне как-то попадалась реклама такоги хостинга, там раздавали не виртуалки, а вполне железные Raspberry Pi, или что-то такого класса. До сих пор жалею, что упустил момент к ним записаться
Здравствуйте, Pzz, Вы писали:
Pzz>На машинке с 4гб поместится 7-8 виртуальных машинок, если каждой выдать по полгига. А поскольку существенную часть цены сервера составляет корпус с блоком питания, а так же место, которое вся эта конструкция занимает в корпусе, я могу себе представить серверный компьютер, в котором несколько процессоров, и у каждого своя личная память, а корпус, питальник и материнская плата — общие. Собственно, мне как-то попадалась реклама такоги хостинга, там раздавали не виртуалки, а вполне железные Raspberry Pi, или что-то такого класса. До сих пор жалею, что упустил момент к ним записаться
Все равно не понятно, как бы могли при современных нагрузках данные машины решать проблемы. Да и физ. площадь датацентров сущесвтенно увеличилось, в разы.
Здравствуйте, Sharov, Вы писали:
S>Согласен, но проведем мысленный эксперимент -- допустим x64 физически невозможно(бред, но все же), люди могут только x32 и все-тут, вселенная такая и законы физики, ничего не поделаешь. В такой вселенной S>возможны были бы облака?
Да без проблем. Тут важно горизонтальное масштабирование. Конкретное ограничение на каждый сервер не существенно.
Здравствуйте, Sharov, Вы писали:
S>Но про айот ... придется забыть.
Этот кайот сюда за уши притянут.
Коллега удачно выразился про заказчика и "новизну" темы: "они так давно этим занимаются... а теперь узнали, что это называется IoT"
Здравствуйте, Sharov, Вы писали:
S>Все равно не понятно, как бы могли при современных нагрузках данные машины решать проблемы. Да и физ. площадь датацентров сущесвтенно увеличилось, в разы.
При больших нагрузках серверную сторону разворачивают на настоящих, а не виртуальных, машинах.
Здравствуйте, Pzz, Вы писали:
S>>Все равно не понятно, как бы могли при современных нагрузках данные машины решать проблемы. Да и физ. площадь датацентров сущесвтенно увеличилось, в разы.
Pzz>При больших нагрузках серверную сторону разворачивают на настоящих, а не виртуальных, машинах.
Slack вполне себе облачный, хотя до нагрузок гугля ему далеко.
Здравствуйте, Sharov, Вы писали:
S>Физ. площади датацентров на всех не хватит.
Если на одной физической машине завести дюжину виртуальных, она мощнее от этого не станет. Поэтому там, где нужна большая нагрузка, нет смысла использовать виртуальные машины. Но зато использование виртуальных машин помогает росту розничных продаж вычислительных мощностей: есть изрядное количество пользователей, которые не готовы платить сотню в месяц за аренду настоящего компьютера, но с удовольствием возьмут маленькую виртуалку за пятерку.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, Sharov, Вы писали:
S>>Физ. площади датацентров на всех не хватит.
Pzz>Если на одной физической машине завести дюжину виртуальных, она мощнее от этого не станет. Поэтому там, где нужна большая нагрузка, нет смысла использовать виртуальные машины. Но зато использование виртуальных машин помогает росту розничных продаж вычислительных мощностей: есть изрядное количество пользователей, которые не готовы платить сотню в месяц за аренду настоящего компьютера, но с удовольствием возьмут маленькую виртуалку за пятерку.
Не спорю, но вот для ентого сценария "на одной физической машине завести дюжину виртуальных" уже нужно x64.
S>Но про айот, бигдату и какой-нибудь слак придется забыть.
Да запросто. При соответствующей оптимизации код ужмётся раз в 10-20.
Бигдата... ну, предполагая что по одному в базе пользователю хранится 25 Кб данных (сессия, покупки в магазине, данные водосчётчика, "горячий" кэш телеграмов и твиттеров), сервер в 4 гигами оперативки обслужит 100 тысяч пользователей. "Холодные" данные можно хранить на диске.
Ну, слегка увеличится время поиска старых твиттерных сообщений в малопопулярном твиттере. Ну, будут на ютубе видосики 240p, а не 1080p.
S>>>Хорошо, а какой в ентом смысл, если у нас всюду 32 бита.
LK>>Ну, допустим, 32 бита. 14-15 виртуалок с 256 мег оперативки (остальное на систему). 256 мег хватит для простейших нужд (веб-сайтик, vpn-сервер, малонагруженная база на мускуле).
S>Ну т.е. ни о каких SAAS, PAAS и прочих *AAS говорить не приходится. Так, для персональных нужд машина.
какие-то наркоманские у вас разговоры. никто не видел 32-бита что ли ?
32-бита накладывают ограничение адресовать в рамках одного процесса, но никаких проблем запустить 1000 процессов и утилизовать 64 гига. оракл в те времена так и работал под линуксами — тучи процессов, вместе жрали десятки гиг на одной 32-бит машине
S>Господа, а правильно ли я понимаю, что в массе своей все енто стало доступно и бурно развивается благодря x64 и 64-битной адресации памяти? Т.е. при x32 енто в принцие невозможно, S>ибо где на 4гб разгуляться? А тут ставишь себе под 200Гб и пару десятков ОС можно хостить. Какие еще железные факторы сделали такой рост возможным -- ssd, рост сетевой пропускной S>способности и т.д., т.е. уменьшение latency до вполне приемлемого уровня. Но в первую очередь, кмк, x64. Софт тут далеко вторичен, кмк.
Для начала хочу сделать мелкое уточнение. Не x32, а x86 (она же IA32 интеловая архитектура 32 бита, у нее есть и другие названия). Затем появилась AMD64 она же x64. А x32 — это особый спецрежим x64, в котором адреса 32-х битные, но доступны все регистры 64-х битной платформы, а их больше, чем на x86. Также, скорее всего, доступны и команды архитектуры amd64. В результате на x32 все равно адресуется только 4Г, как и на x86, но это совсем другой режим. На винде его, кажется никогда не было, на Linux есть. Недавно его пытались из ядра выпилить, но им пользуются, поэтому, его оставили. По тестам за счет меньшего размера указателя он эффективнее использует кеш (указателей в него больше влезает) и дает выигрыш 5-15% по сравнению c x64. У 32-х битного режима тоже выигрывает. Еще есть IA64 (интелловая архитектура 64 бита), но это Итаниум, а не amd64.
4Г памяти для 95% микросервисов вполне достаточно, а их можно и на x86 запустить много. Т.е. за предел 4Г один процесс не выйдет, но все вместе могут использовать очень много памяти. Так что не думаю, что ограничения памяти в 32-х разрядном режиме сильно повлияло.
Облака появились благодаря многим мелким (хотя как посмотреть) улучшениям. Это и 64 бита, и SSD (много микросервисов захотят много IO) и сеть, и размеры дисков. Но главное, на мой взгляд — бурный рост мобилок и других потребителей, для которых нужен сервер. Однако, разработчик редко бывает сисадмином, а разработчиков — одиночек, который может сделать приложение для мобилки и не хочет (да и не может) настраивать свой сервак очень много. Вот и вырос аутсорс серверных приложений, причем, так как разработчику не нужен полноценный виртуальный сервер, а достаточно только одного приложения, то и "виртуализацию" сделали для отдельных приложений (Docker). А также, чтобы разработчику мобилки не нужно было даже серверное приложение писать и в docker его пихать, понаделали разных сервисов, предоставляющих для большинства потребностей полуготовые решения (тут я не ориентируюсь). А дальше придумали новый маркетинговых термин — serverless, который, насколько я понимаю, мало отличается от того, что работает в docker контейнере (возможно, этот контейнер останавливается по таймауту и запускается, когда пришел запрос). Еще говорят про какую-то масштабируемость, но в реальности, 99% пользователей облаков за те же деньги могут купить VPS, за пределы ресурсов которого их приложение никогда не выйдет. В результате стоимость облака в разы выше стоимости VPS, а значит на этот рынок подтянулись многие со своими предложениями и стали активно развивать предлагаемую функциональность. Получился бурный рост.
Все это вместе (приложения в контейнере и развитие этой идеи) и называется теперь облаками и основная их задача — дать разработчику, который не хочет или не может обслуживать сервер (VPS или физический), возможность запускать приложения на сервере. Собственные облака тоже бывают для крупных контор типа гугла или фейсбука, где они крутят микросервисы и сами обслуживают сервера, но не думаю, что они настолько похожи на амазоновское облако на продажу и их облаками называют скорее по привычке (а иногда просто кластером Docker).
S>Как будете раздовать операционки в аренду, если у гипервизора самого 4гб всего?
Насколько я понимаю, Docker запускает приложения с ограничениями по файловой системе, сети, некоторые системные вызовы запрещает. Это не виртуализация, но вполне себе облако. А приложений, каждое из которых будет работать с собственными 4Г памяти на 32-х битной системе можно запустить много.
Pzz>Собственно, мне как-то попадалась реклама такоги хостинга, там раздавали не виртуалки, а вполне железные Raspberry Pi, или что-то такого класса. До сих пор жалею, что упустил момент к ним записаться
Возможно ты про scaleway (эти самые известные ARM хостеры). Но сейчас, они, похоже на другом ARM железе работают (раньше может там и были малинки). Причем если раньше для них ARM был единственным оборудованием, то сейчас они уже давно основным хостингом сделали архитектуру Intel.
Не очень понимаю контекст в котором ты это утверждаешь, но регулярно вижу статьи последние несколько лет, в которых утверждают, что ~30% (или 70%) мощностей в датацентрах простаивают. Причем датацентры строят чем дальше, тем активнее.
Здравствуйте, Sharov, Вы писали:
S>Нет-нет, я говорю про гипотетическую ситуацию, когда у нас все быстрое -- ssd и интернет -- но есть только 32 бита.
Если хочешь, можешь написть про это научно-фантастический роман "32 бита информации" с вселенной, где законами физики запрещено иметь более чем 32 бита разрадности и порассуждать на эту тему.
Здравствуйте, Masterspline, Вы писали:
M>Насколько я понимаю, Docker запускает приложения с ограничениями по файловой системе, сети, некоторые системные вызовы запрещает. Это не виртуализация, но вполне себе облако. А приложений, каждое из которых будет работать с собственными 4Г памяти на 32-х битной системе можно запустить много.
У меня речь идет не столько о сервисах, сколько об инстансах с ОС. Т.е. допустим у нас только x86(32 бита). Итак, у нас есть хост, гипервизор, который уже жрет физически резидентно минимум 1Гб,
и каждый инстанс ОС будет жрать физически 1Гб, итого не больше 3-х виртуалок на одну машину. Мягко говоря не густо, и то что я могу поставить сколько угодно памяти на x86 для 32 битного гипервизора
безразлично. Если только на одной машине не будет крутиться несколько гипервизоров, а енто возможно?
Здравствуйте, Kernan, Вы писали:
S>>Нет-нет, я говорю про гипотетическую ситуацию, когда у нас все быстрое -- ssd и интернет -- но есть только 32 бита. K>Если хочешь, можешь написть про это научно-фантастический роман "32 бита информации" с вселенной, где законами физики запрещено иметь более чем 32 бита разрадности и порассуждать на эту тему.
Я пытаюсь отстоять ту точки зрения, что при множестве факторов, x64 является ключевым.
Здравствуйте, Masterspline, Вы писали:
M>А дальше придумали новый маркетинговых термин — serverless, который, насколько я понимаю, мало отличается от того, что работает в docker контейнере (возможно, этот контейнер останавливается по таймауту и запускается, когда пришел запрос). Еще говорят про какую-то масштабируемость, но в реальности, 99% пользователей облаков за те же деньги могут купить VPS, за пределы ресурсов которого их приложение никогда не выйдет.
serverless — это реально "безсерверные" вычисления, а не просто маркетинговый термин, и не докер. Грубо говоря, ты просто пишешь скрипт, и задаешь условия, когда он будет выполнен (например, при появлении сообщения в очереди сообщений, или появлении некоторого файла в хранилище и т.п.). Сервер для выполнения этого скрипты ты не арендуешь, оно работает "как бы само", без сервера. Платишь ты за каждый запуск скрипта. И таких запусков может быть раз в день, а может миллионы в час. И тебя не волнует сколько для этого нужно арендовать VPS и когда, сломался у тебя сервер или нет, и нужно ли его проапгрейдить.
P.S. В общем, облака — это не только, и не столько аренда VPS, это еще и огромная куча сервисов. Цель все та же — масштабируемость, надежность, скорость развертывания, и эти цели достигаются. Люди — не дураки, и просто за маркетинговые термины платить не хотят.
Gt_>какие-то наркоманские у вас разговоры. никто не видел 32-бита что ли ? Gt_>32-бита накладывают ограничение адресовать в рамках одного процесса, но никаких проблем запустить 1000 процессов и утилизовать 64 гига. оракл в те времена так и работал под линуксами — тучи процессов, вместе жрали десятки гиг на одной 32-бит машине
1)а запустить 4 виртуальных ОС на одной машине, которым физически требуется минимум 1Гб как?
2)а кто отобразит за 4+Гб, если ОС 32 бита? Или имеется в виду файл подкачки каждого процесса держать в памяти, но опять же чем енто поможет 32битной ОС?
Здравствуйте, Sharov, Вы писали:
S>Господа, а правильно ли я понимаю, что в массе своей все енто стало доступно и бурно развивается благодря x64 и 64-битной адресации памяти?
Нет. Облака выстрелили значительно позже массовой доступности х64.
Здравствуйте, Pzz, Вы писали:
Pzz>Я полагаю, облака выстрелили за счет появления подходов к проектированую веб-серверного хозяйства, производительность которого практически линейно массштабируется путем добавления еще компьютеров в нужном количестве. Всякие там микросервисы, map-reduce, NoSQL и т.д. и т.п.
Здравствуйте, Kernan, Вы писали:
S>>Господа, а правильно ли я понимаю, что в массе своей все енто стало доступно и бурно развивается благодря x64 и 64-битной адресации памяти? Т.е. при x32 енто в принцие невозможно K>Я думаю за счёт увелечния каналов свзяи, покрытия и скоростей в первую очередь.
Вы вообще не туда смотрите. Облака это не технология, облака это, прежде всего, услуга. А новые услуги выстреливают потому что на них появляется массовый спрос.
Здравствуйте, Pzz, Вы писали:
Pzz>Если на одной физической машине завести дюжину виртуальных, она мощнее от этого не станет. Поэтому там, где нужна большая нагрузка, нет смысла использовать виртуальные машины
Смысл есть. Хотя бы потому что железо имеет свойство внезапно умирать. Или потому что нагрузка, она со временем меняется.
Если же ты имел в виду, что несколько виртуалок на одной физической машине при росте нагрузки теряют смысл, то тут ты абсолютно прав. Но в облаках нет никаких проблем получить виртуалку с гарантированной производительностью.
И еще один момент — деление, оно разное бывает. Бывает что виртуалки шарят ресурсы. А бывает что нет. Выгоднее воткнуть один сервер с несколькими десятками ядер и кучей памяти, нежели ставить в стойку несколько десятков одноядерных машин.
Gt_>>какие-то наркоманские у вас разговоры. никто не видел 32-бита что ли ? Gt_>>32-бита накладывают ограничение адресовать в рамках одного процесса, но никаких проблем запустить 1000 процессов и утилизовать 64 гига. оракл в те времена так и работал под линуксами — тучи процессов, вместе жрали десятки гиг на одной 32-бит машине
S>1)а запустить 4 виртуальных ОС на одной машине, которым физически требуется минимум 1Гб как? S>2)а кто отобразит за 4+Гб, если ОС 32 бита? Или имеется в виду файл подкачки каждого процесса держать в памяти, но опять же чем енто поможет 32битной ОС?
S>У меня речь идет не столько о сервисах, сколько об инстансах с ОС. Т.е. допустим у нас только x86(32 бита). Итак, у нас есть хост, гипервизор, который уже жрет физически резидентно минимум 1Гб, S>и каждый инстанс ОС будет жрать физически 1Гб, итого не больше 3-х виртуалок на одну машину. Мягко говоря не густо, и то что я могу поставить сколько угодно памяти на x86 для 32 битного гипервизора S>безразлично. Если только на одной машине не будет крутиться несколько гипервизоров, а енто возможно?
где вы такого набрались ? через PAE даже обычная винда прекрасно адресовала 64 гб RAM. т.е. на один хост легко влезает 15 виртуалок с 4 гб рам в каждой.
Здравствуйте, Sharov, Вы писали:
НС>>Нет. Облака выстрелили значительно позже массовой доступности х64. S>Допустим, как енто опровергает мой аргумент?
Что именно ты называешь своим аргументом? Опровергает это не аргумент, а твою теорию о том что обалка выстрелили за счет х64. Если бы это было так, они бы выстрелили намного раньше.
Здравствуйте, Sharov, Вы писали:
S>Я пытаюсь отстоять ту точки зрения, что при множестве факторов, x64 является ключевым.
Тебе вроде уже сказали, что размещение нескольких виртуалок на одной физической машине не есть обязательный признак облака. На куче машин в облаках крутится строго одна виртуалка (для зануд — без учета гипервизора).
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>Допустим, как енто опровергает мой аргумент? НС>Что именно ты называешь своим аргументом? Опровергает это не аргумент, а твою теорию о том что обалка выстрелили за счет х64. Если бы это было так, они бы выстрелили намного раньше.
Здравствуйте, Sharov, Вы писали:
НС>>Что именно ты называешь своим аргументом? Опровергает это не аргумент, а твою теорию о том что обалка выстрелили за счет х64. Если бы это было так, они бы выстрелили намного раньше. S>Не за счет, а без x64.
Здравствуйте, Sharov, Вы писали:
S>>>Не за счет, а без x64. НС>>Ты сабж свой уже забыл что ли?
Видимо забыл.
S>Нет, без x64 облака бы не выстрелили. S> Т.е. нет x64, нет *AAS. Один из ключевых железных факторов.
Еще раз — облака это совсем не про несколько виртуалок на одной физической машине. То о чем ты говоришь называется виртуальный хостинг (ставший доступным существенно раньше облаков), который некоторые ушлые маркетоиды одно время норовили обозвать облаком.
Здравствуйте, Ночной Смотрящий, Вы писали:
S>> Т.е. нет x64, нет *AAS. Один из ключевых железных факторов. НС>Еще раз — облака это совсем не про несколько виртуалок на одной физической машине. То о чем ты говоришь называется виртуальный хостинг (ставший доступным существенно раньше облаков), который некоторые ушлые маркетоиды одно время норовили обозвать облаком.
А изоляция множества сервисов и прочей инфраструктуры за счет чего происходит, на за счет ли виртуалок?
Здравствуйте, Sharov, Вы писали:
S>А изоляция множества сервисов и прочей инфраструктуры за счет чего происходит, на за счет ли виртуалок?
Совсем не обязательно. Современный serverless как правило для этого использует докер. А при приличной нагрузке, о чем тебе уже тоже говорили, одна виртуалка соответствует одной физической машине. Даже в случае serverless. К примеру, в Ажуре, если ты для App Services выбираешь premium tier, то никого кроме тебя на тех же железных ресурсах сидеть не будет. Облако от этого быть облаком не перестает.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Вы вообще не туда смотрите. Облака это не технология, облака это, прежде всего, услуга. А новые услуги выстреливают потому что на них появляется массовый спрос.
Ты не прав. Провайдеров таких услуг не появилось бы будь каналы данных тонкие, конечно, можно говорить что это БИЗНЕС сделал их такими и частично ты будешь прав. А вообще, мне кажется, что рост толщины каналов был спровоцирован порноиндустрией со своими CDN, нагузкой и т.п. Это потом все начали подтягиваться к онлайну.
Здравствуйте, Sharov, Вы писали:
S>Я пытаюсь отстоять ту точки зрения, что при множестве факторов, x64 является ключевым.
Вспомни начало обучения, Эникен. Можно адресовать разными способами, можно собирать адрес из кусочков, можно создать иерархичный адрес. Если бы было ограничение на разрядность, то люди думали бы в направлении как обойти проблему.
Здравствуйте, Kernan, Вы писали:
НС>>Вы вообще не туда смотрите. Облака это не технология, облака это, прежде всего, услуга. А новые услуги выстреливают потому что на них появляется массовый спрос. K>Ты не прав.
Я прав.
K> Провайдеров таких услуг не появилось бы будь каналы данных тонкие,
С тонкими каналами много чего не появилось бы. Но это не значит что облака выстрелили именно за счет их.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Совсем не обязательно. Современный serverless как правило для этого использует докер.
Ну докеры тоже не в вакууме запускают.
НС> А при приличной нагрузке, о чем тебе уже тоже говорили, одна виртуалка соответствует одной физической машине. Даже в случае serverless. К примеру, в Ажуре, если ты для App Services выбираешь premium tier, то никого кроме тебя на тех же железных ресурсах сидеть не будет. Облако от этого быть облаком не перестает.
А вот енто не понятно -- почему так жестко, 1-1, при нагрузке? Пусть у меня 1тб ОЗУ, 64 мощенейщих цпу и т.д., и вот не ентом железе 10-100 виртуалок. И во что, кроме разве сети, мы упремся?
M>>А дальше придумали новый маркетинговых термин — serverless, который, насколько я понимаю, мало отличается от того, что работает в docker контейнере (возможно, этот контейнер останавливается по таймауту и запускается, когда пришел запрос). Еще говорят про какую-то масштабируемость, но в реальности, 99% пользователей облаков за те же деньги могут купить VPS, за пределы ресурсов которого их приложение никогда не выйдет.
Б>serverless — это реально "безсерверные" вычисления, а не просто маркетинговый термин, и не докер. Грубо говоря, ты просто пишешь скрипт, и задаешь условия, когда он будет выполнен (например, при появлении сообщения в очереди сообщений, или появлении некоторого файла в хранилище и т.п.). Сервер для выполнения этого скрипты ты не арендуешь, оно работает "как бы само", без сервера. Платишь ты за каждый запуск скрипта. И таких запусков может быть раз в день, а может миллионы в час. И тебя не волнует сколько для этого нужно арендовать VPS и когда, сломался у тебя сервер или нет, и нужно ли его проапгрейдить.
Для меня облако — это что-то на основе Docker или похожего, т.е. технология для контейнеризации и запуска приложений. Не VPS!!! VPS по сути мало отличается от железного сервера. А там, где нужна масштабируемость, мигранции и тем более быстрое поднятие нового экземпляра, там больше подходит Docker, а не запуск OS со всеми сервисами целиком.
Вот ты говоришь
serverless — это реально "безсерверные" вычисления
Однако твой скрипт где-то будет запускаться. И это мало отличается от контейнеров. В облаке с Docker контейнерами ты задаешь URL, запросы на который будут передавать на твой контейнер и ресурсы контейнера. Где работает контейнер — это уже детали реализации провайдера. Примерно то же происходит и в serverless. Возможно, разница в том, что docker контейнер будет работать все время и ты платишь за время его работы, а serverless скрипт может быть остановлен (и будет запущен при очередном запросе) и ты платишь за каждое его выполнение. Поэтому, реализация работы serverless наверняка оптимизирована на такой режим, но там, скорее всего, будет тот же Docker (или другая система контейнеризации, разработанная провайдером) и тот же маршрутизатор запросов. Также этот режим может накладывать ограничения в виде невозможности использовать базу типа Poostgres, потому что ее каждый раз долго стартовать и поэтому придется пользоваться каким-то сервисом базы данных от провайдера. В общем, отличий мало, как для пользователя, так и в реализации на стороне провайдера. serverless насколько же "безсерверный", как и Docker контейнер в OpenShift.
Если ты что-то знаешь — расскажи, мне интересно, чем отличается по твоему мнению serverless от обычных контейнеров. По довольно поверхностному гуглению я понял, что по сути это тот же Docker, работающий в режиме, когда контейнер со скриптом может быть остановлен, если к нему мало запросов и запущен при приходе нового.
Б>P.S. В общем, облака — это не только, и не столько аренда VPS, это еще и огромная куча сервисов. Цель все та же — масштабируемость, надежность, скорость развертывания, и эти цели достигаются. Люди — не дураки, и просто за маркетинговые термины платить не хотят.
IMHO, VPS это уже давно не облако. Так было раньше, в доDocker'овские времена. Сейчас, если тебе нужна OS, но не нужна мощь железной машины — ты берешь VPS и обслуживаешь его сам. У тебя не будет никаких особых облачных сервисов, да и не нужны они тебе. Если же тебе нужна масштабируемость, быстрый запуск нового экземпляра, мониторинг всей твоей архитектуры, перезапуск зависших приложений — то ты берешь контейнеры на Docker (или другой технологии) и вот тогда тебе вполне может понадобиться хранилище, более функциональное, чем postgres в контейнере и другие сервисы облаков (не очень ориентируюсь, что там есть).
> Люди — не дураки, и просто за маркетинговые термины платить не хотят.
Люди платят за решение своих задач, когда сами их решить не могут или не хотят (есть более приоритетные задачи, например). В 95% случаев, запустив приложение с базой данных в VPS за 5$, а не облаке (Docker) по 20$ за экземпляр и организовав backup, ты никогда не выйдешь за пределы ресурсов VPS, т.е. ни дополнительные сервисы, ни масштабирование тебе не понадобятся. Это очень сэкономит деньги на эксплуатацию, но для этого нужно иметь навыки администрирования и потратить время на начальную настройку и чуть-чуть на обслуживание (читать каждый день письмо, что бакап прошел успешно). Тот кто не умеет админить, платит другим за администрирование (например, за организацию работы облака контейнеров Docker и дополнительных сервисов (типа распределенного хранилища, очереди сообщений или что там еще бывает). И это — нормально. Более того, свой админ в небольшую контору, разрабатывающую мобильные приложения, который обеспечит ту же надежность будет стоить дороже, так что да, люди — не дураки.
Здравствуйте, Sharov, Вы писали:
S>А вот енто не понятно -- почему так жестко, 1-1, при нагрузке?
Потому что никому не нужна непредсказуемость из-за сидящего рядом чужого софта.
S>Пусть у меня 1тб ОЗУ, 64 мощенейщих цпу и т.д., и вот не ентом железе 10-100 виртуалок. И во что, кроме разве сети, мы упремся?
Да во что угодно. В CPU, если у тебя нет выделенных ядер, в шину памяти, в I/O.
Здравствуйте, Masterspline, Вы писали:
M>Однако твой скрипт где-то будет запускаться. И это мало отличается от контейнеров.
Оно совсем не отличается, потому что в виде контейнеров обычно и существует.
M> В облаке с Docker контейнерами ты задаешь URL, запросы на который будут передавать на твой контейнер и ресурсы контейнера. Где работает контейнер — это уже детали реализации провайдера.
Если все на стороне провайдера, то это serverless и есть. Классический же вариант типа AKS предполагает явное указание на каких виртуалках какие контейнеры разворачивать. И отстройка кластера под кубером целиком на твоих плечах.
Еще один бенефит serverless — чем больше у тебя пул серверов, тем меньше на нем сказывается нестабильность нагрузки. В случае serverless пул на стороне провайдера и он очень большой.
M> Примерно то же происходит и в serverless. Возможно, разница в том, что docker контейнер будет работать все время и ты платишь за время его работы, а serverless скрипт может быть остановлен (и будет запущен при очередном запросе) и ты платишь за каждое его выполнение.
А еще в первом случае ты теряешь время на старт машины.
Здравствуйте, Sharov, Вы писали:
S>А вот енто не понятно -- почему так жестко, 1-1, при нагрузке? Пусть у меня 1тб ОЗУ, 64 мощенейщих цпу и т.д., и вот не ентом железе 10-100 виртуалок. И во что, кроме разве сети, мы упремся?
Можно и 10-100 виртуалок запускать — AWS t3-инстансы так и работают. Это идеально подходит для нагрузок типа домашнего веб-сайта, когда нагрузка почти всё время близка к нулю.
Проблема в том, что если хотя-бы часть виртуалок решит проснуться в один и тот же момент, то не хватит мощности. Далее можно мигрировать виртуалки между железом для балансирования на нагрузки, но это практично только для достаточно небольших виртуалок.
Потому для нагруженных серверов берут сервисы, где CPU выделяются эксклюзивно.
Здравствуйте, Masterspline, Вы писали:
M>Для меня облако — это что-то на основе Docker или похожего, т.е. технология для контейнеризации и запуска приложений. Не VPS!!! VPS по сути мало отличается от железного сервера. А там, где нужна масштабируемость, мигранции и тем более быстрое поднятие нового экземпляра, там больше подходит Docker, а не запуск OS со всеми сервисами целиком.
Docker — это один из инструментов. Но облака — это не только запуск контейенров. Это большое количество других сервисов, которые предоставляет провайдер на своих серверах — хранилище данных, очереди сообщений, базы данных, мониторинг, балансировка, безопасность, безсерверные вычисления и еще куча всего.
M>Если ты что-то знаешь — расскажи, мне интересно, чем отличается по твоему мнению serverless от обычных контейнеров. По довольно поверхностному гуглению я понял, что по сути это тот же Docker, работающий в режиме, когда контейнер со скриптом может быть остановлен, если к нему мало запросов и запущен при приходе нового.
Особенность serverless в том, что ты получаешь не сам сервер, а просто возможность исполнять свой код, который на самом деле будет исполняться на серверах провайдера, а не на твоих. При использовании контейнеров — тебе предоставляют (вручную или автоматически) серверы для твоего контейнера. И ты оплачиваешь аренду конкретных серверов.
M>IMHO, VPS это уже давно не облако. Так было раньше, в доDocker'овские времена. Сейчас, если тебе нужна OS, но не нужна мощь железной машины — ты берешь VPS и обслуживаешь его сам. У тебя не будет никаких особых облачных сервисов, да и не нужны они тебе. Если же тебе нужна масштабируемость, быстрый запуск нового экземпляра, мониторинг всей твоей архитектуры, перезапуск зависших приложений — то ты берешь контейнеры на Docker (или другой технологии) и вот тогда тебе вполне может понадобиться хранилище, более функциональное, чем postgres в контейнере и другие сервисы облаков (не очень ориентируюсь, что там есть).
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Sharov, Вы писали: S>>А вот енто не понятно -- почему так жестко, 1-1, при нагрузке? НС>Потому что никому не нужна непредсказуемость из-за сидящего рядом чужого софта. S>>Пусть у меня 1тб ОЗУ, 64 мощенейщих цпу и т.д., и вот не ентом железе 10-100 виртуалок. И во что, кроме разве сети, мы упремся? НС>Да во что угодно. В CPU, если у тебя нет выделенных ядер, в шину памяти, в I/O.
Ага, понял. В моей модели выше предполагалось, что цпу общие для всех виртуалок. Что понимается под выделенной машиной тогда -- физ. место
в серверной у провайдера, или цпу исключительно в личное пользование только нашими виртуалками\сервисами? Т.е. мы точно знаем, что
никто корме нас цпу не использует?
Здравствуйте, Sharov, Вы писали:
S>в серверной у провайдера, или цпу исключительно в личное пользование только нашими виртуалками\сервисами?
А это не важно. Может быть и так и так. Для тебя разницы никакой. Понятно что если ты сейчас закажешь 64-ядерную ВМ, то это будет целиковый комп, но завтра это может оказаться уже половинка от 128-ядерного.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Sharov, Вы писали:
S>>А вот енто не понятно -- почему так жестко, 1-1, при нагрузке? Пусть у меня 1тб ОЗУ, 64 мощенейщих цпу и т.д., и вот не ентом железе 10-100 виртуалок. И во что, кроме разве сети, мы упремся? C>Можно и 10-100 виртуалок запускать — AWS t3-инстансы так и работают. Это идеально подходит для нагрузок типа домашнего веб-сайта, когда нагрузка почти всё время близка к нулю.
C>Проблема в том, что если хотя-бы часть виртуалок решит проснуться в один и тот же момент, то не хватит мощности. Далее можно мигрировать виртуалки между железом для балансирования на нагрузки, но это практично только для достаточно небольших виртуалок.
C>Потому для нагруженных серверов берут сервисы, где CPU выделяются эксклюзивно.
Ох уж эти новые времена, виртуалки всякие...
На мой взгляд, когда у тебя хостится домашний сайт с нулевой нагрузкой, старый добрый сервер с кучей каталогов — этих самых сайтов (ну или одна единственная виртуалка) подойдёт лучше всего.
Упакуй в него тысячи этих сайтиков, и наслаждайся жизнью. К чему на каждого по виртуалке делать, тратить ресурсы на overhead операционок в них, и прочее?
Я вот для себя до сих пор почти не увидел толка от этих новомодных штучек — виртуалок, облаков и иже с ними. Мне от них ни жарко ни холодно.
Здравствуйте, jamesq, Вы писали:
J>Упакуй в него тысячи этих сайтиков, и наслаждайся жизнью. К чему на каждого по виртуалке делать, тратить ресурсы на overhead операционок в них, и прочее?
Для такой микромелочевки есть serverless. А виртуалки нужны только если тебе какое то специфическое окружение требуется, которое на фермах отсутствует.
J>Я вот для себя до сих пор почти не увидел толка от этих новомодных штучек — виртуалок, облаков и иже с ними.
Здравствуйте, Sharov, Вы писали:
C>>Потому для нагруженных серверов берут сервисы, где CPU выделяются эксклюзивно. S>Ага, ясно. А поводу зачина поста и x64 прокомментируете.
По сути, AWS начался до пришествия x64.
AWS создали для того, чтобы использовать простаивающие мощности ЦОД-ов Amazon'а, а в то время весь Amazon был на 32-х битах. Кстати, это интересно из-за того, что первые версии магазина (ещё в 90-х) у них были написаны под 64-битный SPARC, и потом портированы на 32-битный Intel.
Так что на первых доступных инстансах (m1.small, m1.medium) сначала был только x86 (хотя потом почти сразу добавили x64). Последние железно 32-битные инстансы в AWS вывели из эксплуатации только где-то к 2015-му году.
Почему выстрелил? Потому, что многим компаниям стали нужны большие вычислительные мощности. В 90-х годах даже для самых крупных систем просто ставили Один Большой Компьютер и радовались жизни, даже первые версии Гугла работали всего на одном сервере.
Но в середине 2000-х уже никакой компьютер не мог бы справиться с нагрузкой для какого-нибудь среднепопулярного веб-сайта. Ну а дальше как обычно — аренда обходится дешевле, особенно в начале работы. Так что многим проще было заплатить больше AWS за десяток серверов, чем заниматься их организацией самим. Затем сработала "economy of scale" и цены на AWS стали падать быстрее, чем цены на самостоятельный хостинг.
Здравствуйте, jamesq, Вы писали:
C>>Потому для нагруженных серверов берут сервисы, где CPU выделяются эксклюзивно. J>Ох уж эти новые времена, виртуалки всякие... J>На мой взгляд, когда у тебя хостится домашний сайт с нулевой нагрузкой, старый добрый сервер с кучей каталогов — этих самых сайтов (ну или одна единственная виртуалка) подойдёт лучше всего.
Это может быть не просто "домашний сайт", а например, сервер телефонии для небольшой компании. Или
C>Но в середине 2000-х уже никакой компьютер не мог бы справиться с нагрузкой для какого-нибудь среднепопулярного веб-сайта. Ну а дальше как обычно — аренда обходится дешевле, особенно в начале работы. Так что многим проще было заплатить больше AWS за десяток серверов, чем заниматься их организацией самим. Затем сработала "economy of scale" и цены на AWS стали падать быстрее, чем цены на самостоятельный хостинг.
И в итоге, в этом облаке AWS сконцентрировалось ну столько всего, столько всякой разной информации самых различных фирм/людей, что страшно становится.
вот уж у всяких там АНБ раздолье-то.
наверное, надо принимать для облаков, и прочих точек концентрации вычислительных ресурсов специальное законодательство, по типу банковского.
дабы обеспечить отсутствие всяческих инцидентов. банкротство банка сами знаете что может сделать.
а тут аналогично.
Здравствуйте, jamesq, Вы писали:
J>И в итоге, в этом облаке AWS сконцентрировалось ну столько всего, столько всякой разной информации самых различных фирм/людей, что страшно становится. J>вот уж у всяких там АНБ раздолье-то.
Я работал на самом низком уровне инфраструктуры AWS и АНБ там не видел. И честно говоря, не очень представляю как оно там могло бы работать.
J>дабы обеспечить отсутствие всяческих инцидентов. банкротство банка сами знаете что может сделать. J>а тут аналогично.
У AWS есть конкуренты.
Здравствуйте, Cyberax, Вы писали:
J>>вот уж у всяких там АНБ раздолье-то. C>Я работал на самом низком уровне инфраструктуры AWS и АНБ там не видел. И честно говоря, не очень представляю как оно там могло бы работать.
А зачем им быть на самом низком инфраструктурном уровне, когда можно иметь учетки с супер-пупер доступом ко всему?
.
