Комментарии 48
Ранее загрузку с EBS тоже можно было сделать небольшим init скриптом с подменой разделов.
Ещё бы гайды как сделать из существующего образа EBS-bootable…
По-моему, Amazon — не самый лучший выбор, если вы хотите, чтобы иметь хорошую связность с пользователями России и СНГ. Если размещаться на российских хостингах и CDN, то время загрузки страниц пользователями снизиться на несколько секунд по сравнению с Amazon и другими западными хостингами.
Несколько секунд? Вы наверное шутите. Сейчас скорость загрузки больше зависит от клиентского подключения нежели от того где находятся сервера (Если речь идет про современные дата центры). Если приложение пинг-критикал, к примеру игровой сервер линейки или ВОВ, то да, чем ближе к клиенту тем лучше и смысла размещать его далеко нет смысла.
Ну да, да, от клиентского.
Поскольку у меня все сервера в америке, я очень хорошо ощущаю время отклика между российскими и забугорными серверами.
Поскольку у меня все сервера в америке, я очень хорошо ощущаю время отклика между российскими и забугорными серверами.
Не соглашусь с Вами. Как раз сейчас, когда скорости клиентского подключения достаточно высоки, а на сайтах много мультимедийного контента, основную роль играет расстояние от конечного пользователя до веб-сервера.
Как известно, из-за лимита на количество одновременных соединений браузеры загружают изображения и flash-ролики последовательно. Поэтому задержка при загрузке веб-страницы, связанная с бОльшим пингом, возрастает пропорционально количеству размещенных на странице объектов. Увеличение пинга на 50 мс (расстояние до европейских дата-центров из Москвы) и уж тем более на 150 мс (пинг до американских дата-центров) приведет к росту времени загрузки «тяжелых» веб-страниц на 3 — 10 с, что резко ухудшит usability этих страниц.
Как известно, из-за лимита на количество одновременных соединений браузеры загружают изображения и flash-ролики последовательно. Поэтому задержка при загрузке веб-страницы, связанная с бОльшим пингом, возрастает пропорционально количеству размещенных на странице объектов. Увеличение пинга на 50 мс (расстояние до европейских дата-центров из Москвы) и уж тем более на 150 мс (пинг до американских дата-центров) приведет к росту времени загрузки «тяжелых» веб-страниц на 3 — 10 с, что резко ухудшит usability этих страниц.
Спасибо за аргументированный ответ. Тут с Вами сложно поспорить и я тоже вынужден с вами согласиться.
Пишите вполне очевидную чушь (продвигаете какие-то местные сервисы?)
Скорость загрузки страниц не изменится вообще практически, потому что «тяжелый мультимедийный контент» грузится секунды и десятки секунд с ровно такой же скоростью что из Европы что из ДЦ в России, а начальная доп. задержка в десятки миллисекунд — смехотворна.
То что вы пытаетесь рассказать — типичная сказка менеджеров российских хостеров и ДЦ.
Дело не в задержке дополнительной 50ms, а в качестве канала.
Учиытывая, что из России сейчас в Европу идут сотни и сотни гигабит линков (RETN, Telia-Sonera, куча других) — хостинг бизнесу в России скоро придется ну очень туго — надо будет поднимать качество и снижать цены, что очень уж не любят делать ;)
Скорость загрузки страниц не изменится вообще практически, потому что «тяжелый мультимедийный контент» грузится секунды и десятки секунд с ровно такой же скоростью что из Европы что из ДЦ в России, а начальная доп. задержка в десятки миллисекунд — смехотворна.
То что вы пытаетесь рассказать — типичная сказка менеджеров российских хостеров и ДЦ.
Дело не в задержке дополнительной 50ms, а в качестве канала.
Учиытывая, что из России сейчас в Европу идут сотни и сотни гигабит линков (RETN, Telia-Sonera, куча других) — хостинг бизнесу в России скоро придется ну очень туго — надо будет поднимать качество и снижать цены, что очень уж не любят делать ;)
Время пинга, к сожалению, определяется не только шириной каналов, но и географической удаленностью дата-центров от пользователей. Сколько бы Вы не расширяли каналы до Европы, быстрее 50 мс пинг у вас не будет — это определяется скоростью света, а ее пока никто не научился менять :)
Пусть на вашей веб-странице находится 100 изображений. IE имеет ограничение на 2 одновременно открытые сессии с одним доменом. В результате, задержка загрузки страницы будет равна пингу, увеличенному в 50 раз, т.е. 2,5 с для Европы и 7,5 с для Америки.
Если бы проблемы задержек при доставке контента не существовало, то не существовало бы и такого бизнеса, как CDN (Content Delivery Network). А именно на Западе, где каналов, как Вы сами говорите, более, чем достаточно, рынок CDN давно существует, растет и оценивается в 2 млрд долларов в год. См. исследование Frost & Sullivan: www.slideshare.net/FrostandSullivan/cdn-market-improving-but-latest-pricing-data-shows-challenges-still-lie-ahead
Пусть на вашей веб-странице находится 100 изображений. IE имеет ограничение на 2 одновременно открытые сессии с одним доменом. В результате, задержка загрузки страницы будет равна пингу, увеличенному в 50 раз, т.е. 2,5 с для Европы и 7,5 с для Америки.
Если бы проблемы задержек при доставке контента не существовало, то не существовало бы и такого бизнеса, как CDN (Content Delivery Network). А именно на Западе, где каналов, как Вы сами говорите, более, чем достаточно, рынок CDN давно существует, растет и оценивается в 2 млрд долларов в год. См. исследование Frost & Sullivan: www.slideshare.net/FrostandSullivan/cdn-market-improving-but-latest-pricing-data-shows-challenges-still-lie-ahead
Зачем врать? Или просто не знать элементарных вещей?
Ограничения не на домен — а на IP. Никто не мешает на один проект (мы так и делаем) хоть 10 IP вешать — одно доменное имя, пачка адресов.
Насчет сказочников из CDN — это маркетинговая туфта, так же как и стоимость рынка.
Видите-ли, я построил не один и не два крупных (на десятки миллионов пользователей) проекта в России и на западе. Из русских — это mamba.ru и begun.ru например.
Каждый раз, когда подкатывали CDNщики — в итоге уходили несолоно хлебавши, потому что все что они нам могут предложить — мы делаем сами и в десятки / сотни раз дешевле.
Еще раз — все что вы написали про «десятки секунд загрузку страниц» — вполне очевидная чушь (или просто заблуждения).
Длинные но качественные линки «опасны» только для тяжелых игровых приложений — стрелялок и чуток для войса. Вот практически и все.
Ограничения не на домен — а на IP. Никто не мешает на один проект (мы так и делаем) хоть 10 IP вешать — одно доменное имя, пачка адресов.
Насчет сказочников из CDN — это маркетинговая туфта, так же как и стоимость рынка.
Видите-ли, я построил не один и не два крупных (на десятки миллионов пользователей) проекта в России и на западе. Из русских — это mamba.ru и begun.ru например.
Каждый раз, когда подкатывали CDNщики — в итоге уходили несолоно хлебавши, потому что все что они нам могут предложить — мы делаем сами и в десятки / сотни раз дешевле.
Еще раз — все что вы написали про «десятки секунд загрузку страниц» — вполне очевидная чушь (или просто заблуждения).
Длинные но качественные линки «опасны» только для тяжелых игровых приложений — стрелялок и чуток для войса. Вот практически и все.
Про «десятки секунд» не писал. Даже 500 мс уже достаточно для ухудшения usability (см. данные Гугл ниже).
Использовать или не использовать CDN — зависит от задач, навыков и убеждений владельца каждого конкретного проекта. Заметьте, я вовсе не агитировал здесь за CDN. Я лишь утверждал, что если ваша аудитория — российская, то и контент надо размещать в России. Я знаю много проектов (YouDo, Skillopedia и др.), которые сидели на западных серверах, но потом переехали в Россию, потому что связность с их аудиторией здесь гораздо лучше. Или Вы хотите сказать, что mamba и begun работают на западных хостингах? Ведь нет же.
Использовать или не использовать CDN — зависит от задач, навыков и убеждений владельца каждого конкретного проекта. Заметьте, я вовсе не агитировал здесь за CDN. Я лишь утверждал, что если ваша аудитория — российская, то и контент надо размещать в России. Я знаю много проектов (YouDo, Skillopedia и др.), которые сидели на западных серверах, но потом переехали в Россию, потому что связность с их аудиторией здесь гораздо лучше. Или Вы хотите сказать, что mamba и begun работают на западных хостингах? Ведь нет же.
мамба и бегун строились лет 7 назад. Надеюсь, мне не надо рассказывать такие тривиальные вещи как:
тот же RETN запустил на запад более 200 гигабит только в этом году. И еще тонны будут запускать. Это только ОДИН оператор.
Ребятки — вашему CDN просто тупо не жить.
Опять же тот же RETN приходит в города имея минимум 100 гбит. Они уже пошли на Юг (в Воронеже, вот-вот будут в Ростове на Дону, идут в Краснодар), север у них и так очень неплохо — а еще имеем RtCom, TTK и прочих…
Я определенно знаю о чем говорю — у нас трафика только в России более 40 гбит уже.
тот же RETN запустил на запад более 200 гигабит только в этом году. И еще тонны будут запускать. Это только ОДИН оператор.
Ребятки — вашему CDN просто тупо не жить.
Опять же тот же RETN приходит в города имея минимум 100 гбит. Они уже пошли на Юг (в Воронеже, вот-вот будут в Ростове на Дону, идут в Краснодар), север у них и так очень неплохо — а еще имеем RtCom, TTK и прочих…
Я определенно знаю о чем говорю — у нас трафика только в России более 40 гбит уже.
а зачем сервера у бегуна в Украине? или их нет в Украине? для укр. пользователей?
Да всё там нормально со временем загрузки… я достаточно долгое время всю графику сайта отдавал со штатовского амазон-сервера, никто ни разу даже не пожаловался. Нормально настроенное клиентсткое кэширование — и пользователь не замечает, в Штатах машина или в Москве.
Амазон выбирают потому что он а) надёжный, б) относительно недорогой, в) с внятным и прозрачным биллингом, г) полностью управляемый без звонков и пива саппорту. А покажите мне хоть один российский CDN, у которого хотя бы цены на сайте будут явно написаны.
Амазон выбирают потому что он а) надёжный, б) относительно недорогой, в) с внятным и прозрачным биллингом, г) полностью управляемый без звонков и пива саппорту. А покажите мне хоть один российский CDN, у которого хотя бы цены на сайте будут явно написаны.
+ Все молчат о самом главном преимуществе клаудов. При котором ты платишь только за то что используешь. Почасовая оплата… На базе этого отлично строится схема горизонтального массштабирования проекта. Не справляется апач с нагрузкой, поднял новый, нагрузка спала, опустил…
Цены у российского CDN можно получить, написав письмо мне и указав, какой у Вас исходящий трафик и объем хранилища :)
А по поводу «пользователи не замечают» не соглашусь с Вами. Вот что, например, пишет по этому поводу известные компании, в том числе любимый Вами Amazon: каждые 100 мс задержки приводит к падениям продаж Интернет-магазина на 1%. Пруфлинк: www.slideshare.net/stubbornella/designing-fast-websites-presentation
ну зачем же так активно «толкать» свой CDN сервис? теперь понятно откуда ветер дует :)))))))
… непонятно на каких данных основанная презенташка, смешные цифры в 1% — которые укладываются просто в погрешность измерений, и тд и тп.
… непонятно на каких данных основанная презенташка, смешные цифры в 1% — которые укладываются просто в погрешность измерений, и тд и тп.
Там еще есть одна «смешная» цифра от Гугл — 500 мс задержки приводят к уменьшению количества поисковых запросов на 20%
круто. вот только у меня на спутниковом модеме и то задержки редко выше 200 мс поднимаются в любой точке мира :D
p.s. ну хватит уже втирать…
p.s. ну хватит уже втирать…
Какие 200 мс на спутниковом модеме? Ниже 550 мс не может быть по определению, почитайте учебник физики за 8 класс (спутник висит на геостационарной орбите совершенно определенной высоты).
Ну опять или врем или просто не думаем головой…
«If you are located on the equator and are communicating with a satellite directly overhead then the total distance (up and down again) is nearly 72,000 km so the time delay is 240 ms.»
«If you are located on the equator and are communicating with a satellite directly overhead then the total distance (up and down again) is nearly 72,000 km so the time delay is 240 ms.»
Ну, и вдобавок — похоже у кого-то с образованием все достаточно плохо ;)
Для начала — у меня Iridium (новые аппараты очень хороши и имеют USB порт), который LEO (см. ниже)
Далее:
However, Medium Earth Orbit (MEO) and Low Earth Orbit (LEO) satellites do not have such great delays. The current LEO constellations of Globalstar and Iridium satellites have delays of less than 40 ms round trip, but their throughput is less than broadband at 64 kbps per channel. The Globalstar constellation orbits 1,420 km above the earth and Iridium orbits at 670 km altitude. The proposed O3b Networks MEO constellation scheduled for deployment in 2010 would orbit at 8,062 km, with RTT latency of approximately 125 ms. The proposed new network is also designed for much higher throughput with links well in excess of 1 Gbps (Gigabits per second).
Для начала — у меня Iridium (новые аппараты очень хороши и имеют USB порт), который LEO (см. ниже)
Далее:
However, Medium Earth Orbit (MEO) and Low Earth Orbit (LEO) satellites do not have such great delays. The current LEO constellations of Globalstar and Iridium satellites have delays of less than 40 ms round trip, but their throughput is less than broadband at 64 kbps per channel. The Globalstar constellation orbits 1,420 km above the earth and Iridium orbits at 670 km altitude. The proposed O3b Networks MEO constellation scheduled for deployment in 2010 would orbit at 8,062 km, with RTT latency of approximately 125 ms. The proposed new network is also designed for much higher throughput with links well in excess of 1 Gbps (Gigabits per second).
Время пинга = время прохождения сигнала от пользователя до сервера и обратно (т.е. при пинге через спутниковый модем расстояние от Земли до спутника проходится 4 раза). Значит, время задержки 240 мс (для экватора) надо умножить на 2 и как раз получим цифру около 480 мс для экватора (а для наших широт — около 550 мс).
Это для обычных спутников, висящих на геостационарных орбитах. Спутники GlobalStar и Iridium висят не на геостационарных, а на более низких наклонных орбитах, поэтому у них время пинга действительно ниже. Только вот стоимость трафика в этих спутниковых системах крайне высока.
Поделюсь еще одним знанием, чтобы повысить кое-чей уровень образования: длинный пинг приводит к большому времени ожидания загрузки веб-страниц в том числе и из-за используемого в TCP механизма плавающего окна (специально для Вас, по английски это будет TCP sliding window mechanism). Этот механизм служит для того, чтобы установить максимально возможную скорость TCP-соединения между сервером и клиентом, при этом размер окна увеличивается с 512 байт (значение по умолчанию) до оптимального значения (т.е. максимального значения размера окна, при котором данные не теряются). Так вот, время увеличения TCP-окна с дефолтного значения до оптимального по крайней мере в несколько раз больше времени пинга. Поэтому при коротких TCP-соединениях, устанавливаемых при веб-браузинге, на спутниковых каналах наблюдается недоиспользование спутниковой полосы и, как следствие, низкая скорость соединения. Поэтому спутниковые операторы вынуждены применять специальные TCP-акселераторы, которые ускоряют процесс установления TCP-окна (см. www.sky-vision.net/whitepapers/Managing_TCP_Over_Satellite.pdf).
Это для обычных спутников, висящих на геостационарных орбитах. Спутники GlobalStar и Iridium висят не на геостационарных, а на более низких наклонных орбитах, поэтому у них время пинга действительно ниже. Только вот стоимость трафика в этих спутниковых системах крайне высока.
Поделюсь еще одним знанием, чтобы повысить кое-чей уровень образования: длинный пинг приводит к большому времени ожидания загрузки веб-страниц в том числе и из-за используемого в TCP механизма плавающего окна (специально для Вас, по английски это будет TCP sliding window mechanism). Этот механизм служит для того, чтобы установить максимально возможную скорость TCP-соединения между сервером и клиентом, при этом размер окна увеличивается с 512 байт (значение по умолчанию) до оптимального значения (т.е. максимального значения размера окна, при котором данные не теряются). Так вот, время увеличения TCP-окна с дефолтного значения до оптимального по крайней мере в несколько раз больше времени пинга. Поэтому при коротких TCP-соединениях, устанавливаемых при веб-браузинге, на спутниковых каналах наблюдается недоиспользование спутниковой полосы и, как следствие, низкая скорость соединения. Поэтому спутниковые операторы вынуждены применять специальные TCP-акселераторы, которые ускоряют процесс установления TCP-окна (см. www.sky-vision.net/whitepapers/Managing_TCP_Over_Satellite.pdf).
жаль пока гентушных ebs images нету :( так бы уже запустил, потестил
Никогда не понимал этого евангелизма )
«Я работаю только с одной осью, а остольное с презрением отбрасываю» :-)
«Я работаю только с одной осью, а остольное с презрением отбрасываю» :-)
Вы администрировали хотя бы 5ку серверов с 2\3\4-мя разными осями? попробуйте, очень быстро поймёте, что евангелизм тут ни при чём :)
да просто если пробовать, то затачивать под себя, nginx, php, mysql, мемкеши всякие и т.д. и т.п. просто лень сначала под одну ось собирать, потом под другую, потому как все равно буду на генте, просто привык и удобно :)
> 2. Можно забыть про трудоемкий и геморный процесс создания снапшота системы (именуеммый бандлом). Теперь чтобы сделать снапшот системы, достаточно просто 1 АПИ вызовом создать снапшот EBS вольюма.
> 3. Возможность приостанавливать работу инстанса. Раньше мы могли только запустить и удалить инстанс. Теперь мы можем приостановить его (аналог Suspend). При этом за инстансом сохраняется его ID и настройки и вы можите всегда его оживить.
А можно привести пару примеров, чтобы обычный смертный PHP-шник, работающий с VDS через SSH понял, как ему это задействовать?
> 3. Возможность приостанавливать работу инстанса. Раньше мы могли только запустить и удалить инстанс. Теперь мы можем приостановить его (аналог Suspend). При этом за инстансом сохраняется его ID и настройки и вы можите всегда его оживить.
А можно привести пару примеров, чтобы обычный смертный PHP-шник, работающий с VDS через SSH понял, как ему это задействовать?
Пару примеров чего? Для чего использовать EC2? Я знаю к примеру 2 очень выгодных юзкейса для него:
1. Для дэвелопминга: Запустил сервер потестил остановил. И тестинг происходит на живом окружении а не на денвере каком-то.
2. Для высоконагруженных проектов. В случае с выделенными серверами нужно всегда иметь не маленький запас мощности сервера(ов), к примеру для хабраэфекта. В случае с ЕЦ2, можно скалировать (запускать новые ноды) в зависимости от нагрузки. К примеру ваш проект хостится на инстанте типа m1.small (1GHz Celeron). И 90% случаеев его мощьности полностью хватает. Вы запостили статью на хабре и пропиарили ваш отличный проект. На него ломануись люди. В случае с выделенными серверами, если бы у вас небыло запаса мощности вы бы потеряли 10 милионов доларов прибыли, в случае с ЕЦ2 вы запустите парочку дополнительных инстансов на вермя хабраэфекта и остановите их когда хабраэфект пройдет. Результат: ваш сайт не упал под натиском пользователей хабра. Это довольно утрированный пример, но принцинципы должны быть понятны.
1. Для дэвелопминга: Запустил сервер потестил остановил. И тестинг происходит на живом окружении а не на денвере каком-то.
2. Для высоконагруженных проектов. В случае с выделенными серверами нужно всегда иметь не маленький запас мощности сервера(ов), к примеру для хабраэфекта. В случае с ЕЦ2, можно скалировать (запускать новые ноды) в зависимости от нагрузки. К примеру ваш проект хостится на инстанте типа m1.small (1GHz Celeron). И 90% случаеев его мощьности полностью хватает. Вы запостили статью на хабре и пропиарили ваш отличный проект. На него ломануись люди. В случае с выделенными серверами, если бы у вас небыло запаса мощности вы бы потеряли 10 милионов доларов прибыли, в случае с ЕЦ2 вы запустите парочку дополнительных инстансов на вермя хабраэфекта и остановите их когда хабраэфект пройдет. Результат: ваш сайт не упал под натиском пользователей хабра. Это довольно утрированный пример, но принцинципы должны быть понятны.
Спасибо, но это всё я давно понял из множества статей.
Я про конкретику.
Вот сейчас типичный алгоритм развёртывания проекта:
1. Заказываю VDS, оплачиваю через Webmoney.
2. Выбираю дистрибутив из списка, ставлю на VDS, настраиваю нужные мне службы: apache+php, mysql, svn.
3. Настраиваю хост: домен, виртуалхост, разворачиваю файлы из svn, настраиваю права записи.
4. Всё работает.
А как с EC2?
Мне вот вообще непонятно, за что взяться: как заказать? как оплатить? как поднять там нужный мне дистрибутив? будет ли отличаться доступ и настройка этого узла через SSH от аналогичной настройки VDS?
Если использовать их же БД — она не SQL, как её прикрутить к PHP-проекту?
Как настраивается и регулируется динамическое добавление ресурсов? Как мне не попасть на деньги при простейшей DOS-атаке? Пусть лучше хост ляжет, чем я останусь должен тысячи долларов.
Спасибо и успехов.
Я про конкретику.
Вот сейчас типичный алгоритм развёртывания проекта:
1. Заказываю VDS, оплачиваю через Webmoney.
2. Выбираю дистрибутив из списка, ставлю на VDS, настраиваю нужные мне службы: apache+php, mysql, svn.
3. Настраиваю хост: домен, виртуалхост, разворачиваю файлы из svn, настраиваю права записи.
4. Всё работает.
А как с EC2?
Мне вот вообще непонятно, за что взяться: как заказать? как оплатить? как поднять там нужный мне дистрибутив? будет ли отличаться доступ и настройка этого узла через SSH от аналогичной настройки VDS?
Если использовать их же БД — она не SQL, как её прикрутить к PHP-проекту?
Как настраивается и регулируется динамическое добавление ресурсов? Как мне не попасть на деньги при простейшей DOS-атаке? Пусть лучше хост ляжет, чем я останусь должен тысячи долларов.
Спасибо и успехов.
Все очень просто:
1. Регистрируетесь на Amazon AWS. Вводите данные своей карточки. Билитесь вы раз в месяц за то что использовали. Тоесть заюзали вы инстансов на 20 баксов, вы автоматом пробилитесь на 20 баксов.
2. Получаете в профиле ключи от API и используете его. Там либо SOAP либо REST. Документации валом. Можите использовать платные сервисы такие как Rightscale (стоит очень дорого) или наш scalr.net. Эти сервисы помогают разворачивать и настраивать вам фермы (группы серверов). Больше инфы можите найти на сайтах. Есть еще вариант использования Amazon Management Console. Это просто графическая оболочка вокруг АПИ.
3. При запуске инстанса вы выбираете image (snapshot) системы. Убунту, ЦентОс, Шапка. И Так далее…
4. Доступ к инстансам такой же как и к обычным серверам. Есть рутовый SSH. Со всеми вытекающими.
5. В случае с БД, есть 3 варианта:
— Испольщовать их SimpleDB (не SQL)
— Использовать их новый сервис RDS. А это уже MySQL 5.1 но этот сервис в бете.
— На своем инстансе установить мускуль или любую другую базу и использовать его.
6. В случае с Ддосом, насколько я знаю у амазона есть защита от ддосных аттак, но точное не скажу. Нужно спрашивать у них.
Тоесть алгоритм развертывания проекта точно такой же за исключением пунтка 1. :-)
1. Регистрируетесь на Amazon AWS. Вводите данные своей карточки. Билитесь вы раз в месяц за то что использовали. Тоесть заюзали вы инстансов на 20 баксов, вы автоматом пробилитесь на 20 баксов.
2. Получаете в профиле ключи от API и используете его. Там либо SOAP либо REST. Документации валом. Можите использовать платные сервисы такие как Rightscale (стоит очень дорого) или наш scalr.net. Эти сервисы помогают разворачивать и настраивать вам фермы (группы серверов). Больше инфы можите найти на сайтах. Есть еще вариант использования Amazon Management Console. Это просто графическая оболочка вокруг АПИ.
3. При запуске инстанса вы выбираете image (snapshot) системы. Убунту, ЦентОс, Шапка. И Так далее…
4. Доступ к инстансам такой же как и к обычным серверам. Есть рутовый SSH. Со всеми вытекающими.
5. В случае с БД, есть 3 варианта:
— Испольщовать их SimpleDB (не SQL)
— Использовать их новый сервис RDS. А это уже MySQL 5.1 но этот сервис в бете.
— На своем инстансе установить мускуль или любую другую базу и использовать его.
6. В случае с Ддосом, насколько я знаю у амазона есть защита от ддосных аттак, но точное не скажу. Нужно спрашивать у них.
Тоесть алгоритм развертывания проекта точно такой же за исключением пунтка 1. :-)
1. Какая карточка нужна? Я ими просто не пользуюсь. У меня лежит какая-то старая сбербанковская — как узнать, подойдёт ли она? Если нет, то где нужно взять такую, чтобы принималась к оплате Амазоном?
2. Было бы интересно увидеть real-life примеры использования API (именно не из документации, а из серии «на нашем проекте мы делаем так:...») и/или обзор Amazon Management Console.
3. Образы подготовлены Амазоном?
Как после настройки образа сохранить его? Во-сколько мне это обойдётся?
4. ОК.
5. Спасибо, стало понятнее.
6. Вот как раз больше всего меня настораживает, что всё по отдельности вроде стоит недорого, но когда всё вместе начинает работать, у меня ощущение потери контроля над расходованием средств — ведь плата снимается за каждый «чих». И на первый взгляд, атакой извне можно спровоцировать вполне легальное сведение баланса к нулю.
Спасибо за пояснения.
2. Было бы интересно увидеть real-life примеры использования API (именно не из документации, а из серии «на нашем проекте мы делаем так:...») и/или обзор Amazon Management Console.
3. Образы подготовлены Амазоном?
Как после настройки образа сохранить его? Во-сколько мне это обойдётся?
4. ОК.
5. Спасибо, стало понятнее.
6. Вот как раз больше всего меня настораживает, что всё по отдельности вроде стоит недорого, но когда всё вместе начинает работать, у меня ощущение потери контроля над расходованием средств — ведь плата снимается за каждый «чих». И на первый взгляд, атакой извне можно спровоцировать вполне легальное сведение баланса к нулю.
Спасибо за пояснения.
примерно 2 года держу клиента на сервер, small instance с подменой рута на ebs
полет отличный
если можно стартануть с ebs напрямую это намного упрощает дело.
полет отличный
если можно стартануть с ebs напрямую это намного упрощает дело.
Читайте документацию. Там всё простое как валенок, куча примеров, куча гайдов. Читайте и будет Вам счастье. А если не будет то, извините, значит эта система не для Вас. Хотя мне трудно такое представить.
Карточки подходит Visa (не Electron) и Mastercard.
Карточки подходит Visa (не Electron) и Mastercard.
а чтобы всем этим рулить есть плагин для FF elasticfox, странно что про него не все знают. он насколько я помню упоминается в документации амазона
Теперь чтобы сделать снапшот системы, достаточно просто 1 АПИ вызовом создать снапшот EBS вольюма
Если я правильно понял, то так можно и бэкапиться?
Если я правильно понял, то так можно и бэкапиться?
блин, охото поиграться с этим сервисом :(
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Новые возможности от Amazon для EC2 сервиса