Amazon EC2
Эти ваши облака - творчество психов.
Я теперь понимаю, откуда у iron.io айседного были покупатели - нормальный человек ебань, которой обставлены виртуалки в EC2 должен обходить десятой дорогой.
Вот например, у виртуалки hostname - это ее внутренний DNS адрес. А он меняется при рестарте. А чтобы докинуть процессоров или памяти - нужно рестартовать инстанс. Ну и в итоге, смотришь на несколько консолей на несколько инстансов и хер поймешь, где ты находишься, пока в .bashrc промпты и заголовки руками не вобьешь. И внешний адрес тоже меняется, пока к ней elastic ip гвоздями не прибьешь. И сторадж - 400 гиг локального instance store, который после рестарта пропадет к херам, а все что персистент - то EBS за деньги. Дополнительный гарантированный i/o на EBS - тоже за деньги. Причем, что характерно, раздела "обороты по лицевому счету", где можно было бы посмотреть, сколько это все жрет бабла в разрезе - я не нашел.
А вы говорите, Firebird на компах секретарш. :)
Я теперь понимаю, откуда у iron.io айседного были покупатели - нормальный человек ебань, которой обставлены виртуалки в EC2 должен обходить десятой дорогой.
Вот например, у виртуалки hostname - это ее внутренний DNS адрес. А он меняется при рестарте. А чтобы докинуть процессоров или памяти - нужно рестартовать инстанс. Ну и в итоге, смотришь на несколько консолей на несколько инстансов и хер поймешь, где ты находишься, пока в .bashrc промпты и заголовки руками не вобьешь. И внешний адрес тоже меняется, пока к ней elastic ip гвоздями не прибьешь. И сторадж - 400 гиг локального instance store, который после рестарта пропадет к херам, а все что персистент - то EBS за деньги. Дополнительный гарантированный i/o на EBS - тоже за деньги. Причем, что характерно, раздела "обороты по лицевому счету", где можно было бы посмотреть, сколько это все жрет бабла в разрезе - я не нашел.
А вы говорите, Firebird на компах секретарш. :)
no subject
(no subject)
(no subject)
(no subject)
no subject
Так что это просто разные сорта, но все это Г.
(no subject)
(no subject)
(no subject)
no subject
(no subject)
(no subject)
(no subject)
(no subject)
(Anonymous) - 2013-08-31 16:22 (UTC) - Expand(no subject)
(no subject)
no subject
Половина озвученных вами проблем - всего лишь дефолтные настройки, они меняются.
Другая половина - часть концепции, и если вдуматься, все там достаточно правильно.
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
no subject
(no subject)
no subject
Для адресов нужно свои костыли приделывать. Например поднимать dyndns и в образ класть скрипт, который при старте будет регистрировать себя в dns с осмысленным имененем. Осмысленное имя имеет смысл делать CNAME-ом на амазоновское DNS имя. Так как оно снаружи ресолвится на внешний адрес, а изнутри инстансы ресолвят друг друга по внутреннему адресу.
Постоянный внешний адрес можно организовать ещё с помощью ELB, приделать к нужному инстансу балансер. Балансер умеет перенаправлять запросы на нужный инстанс в независимости от его адреса. А на самом балансере DNS постоянный на всём времени жизни.
Онлайнового добавления процессоров и памяти, как и живой миграции внутри ec2 нет. Например в определённый момент по каждому инстансу вам придёт письмо о том, что они решили провести профилактику на железном сервере и надо бы рестартануть инстанс для переноса его на другой железный сервер. Иначе они сделают это сами. Кстати, падение инстансов это тоже не редкая ситуация.
У EC2 основная цель это масштабирование. Сделать так, чтобы работало стотыщмиллионов инстансов и других сущностей. И они с этим справляются. Фичи, хоть как-то мешающие работе на больших масштабах, они осознанно урезают и не делают. И по поводу стабильности особо не парятся.