Amazon очень круто снижает цены на свой виртуальный хостинг EC2 с 1 апреля 2014 года.
На многие инстансы цены падают до 40%. Новые цены.
Например, инстанс m3.medium: 1 процессор с 3 комп. юнита, память 3.75 Гб и 1 x 4 SSD диск (без учёта SSD) — стоил $0.113 в час, а с 1 апреля будет стоит $0.07 в час. Это 50 долларов в месяц против 80-и. C учётом покупки пакетов Reserved Instance на год или на три, цену можно уменьшить почти в два раза за месяц.
Т.е. Amazon становится всё более и более привлекательным для построения средних и больших интернет проектов с учётом всей его инфраструктуры. Правда самый дешёвый t1.micro инстанс так и не подешевёл, для этого рекомендую использовать Digital Ocean, он в плане цены и скорости, просто вне конкуренции.
Чуть больше года назад подробно расписывал, как работать с Amazon EC2 — крупнейшим облачным хостингом, позволяющим создавать гибкие виртуальные сервера и экономить время и деньги (мои посты тут и тут).
Но конкуренция в отрасли растёт (что хорошо) и я переехал на Digital Ocean — сейчас, это наверное самый динамично развивающийся облачный хостер в мире. Самое интересное предложение у Digital Ocean, виртуальная машина с 20 Гб SSD диском, 512 Мб памяти и 1 Гб трафика в месяц, которая стоит всего 5$ в месяц. В сентябре 2013, когда я создал там первую виртуальную машину, там было 600 тыс серверов, сейчас (Март 2014) уже 1 млн 200 тыс виртуальных машин! Такой базовой машины вполне хватает для размещения небольшого сайта или различных сервисов, например это блог работает на таком отдельном сервере, несколько серверов использую для работы, в том числе и для тестирования.
5$ виртуальную машину стоит сравнить с t1.micro инстансом от Amazon.
Digital Ocean — 5$ в месяц Память: 512 Мб
Диск: 20 Гб SSD
Трафик: 1 Tб входит в стоимость
Amazon EC2 t1.micro — 14.4$ в месяц Память: 615 Мб
Диск: от 8 Гб EBS (1$ за каждые 10 Гб)
Трафик: 1 Tб входит в стоимость
1. Цена
По стоимости (учитывая диск) — t1.micro проигрывает в 3 раза
2. Диск
EBS диск у t1.micro крайне медленный, SSD у Digital Ocean гораздо быстрее.
Обратная сторона, что EBS это диск «в облаке» и шанс его потерять очень мал, а SSD на диске обычного сервера, т.е. требуется бэкап (у Digital Ocean он стоит 20% от типа виртуального сервера, т.е. тут это 1$ в месяц).
3. Процессор
Самая главная проблема Amazon EC2 — скорость процессора медленее чем на Digital Ocean (это касается не только этого типа инстанса, но и более дорогих), я не могу точно сказать во сколько раз, но субьективно Digital Ocean быстрее как минимум, в несколько раз (тест).
4. Память Digital Ocean чуть проигрывает (на 20%). Нужно обязательно ставить x32 операционную систему, для экономии памяти. Я например использую Ubuntu 12.04 LTS x32.
По моему опыту (запускал с десяток серверов на EC2 и штук пять Digital Ocean) Digital Ocean гораздо быстрее, рекомендую его для размещения небольших проектов. Причём Digital Ocean явно сейчас не является прямым конкурентом Amazon, они пересекаются в самом недорогом сегменте и у Digital Ocean нет того количества сервисов как у Amazon.
P.s. Стоит упомянуть, что покупая «reserved instance», можно снизить цену на Amazon на t1.micro почти до 5$ в месяц, но это точно не очень удобно, т.к. нужно заплатить сразу 100$, чтобы получить скидку на пользование за 3 года вперёд.
В каждом датацентре Amazon несколько зон (Availabilty Zone), каждая зона — это физически отделённый датацентр (разное питание, здание, подключение к интернету) от других, чтобы в случае падения одного, минимизировать влияние на другие.
Иногда нужно сделать перенос инстанса c одной зоны в другую. Например, я переносил свой сервер с us-east-1a на us-east-1b. Мне нужно было переносить сервер, т.к. я купил Reservation план для другой зоны, а планы резервации работают, только если зона сервера совпадает с зоной купленной резервации.
Шаги следующие:
1. Запускаем новый инстанс в нужной новой Availability зоне. Тут можно выбрать любой линукс и любой ключ доступа, логинится на него не будем, главное выбрать правильный тип сервера и правильную (новую) зону.
2. После запуска инстанса, сразу останавливаем его (щёлкаем правой кнопкой и выбираем Stop).
3. Идём в раздел Volumes, находим EBS диск принадлежащий запущенному новому серверу, отключаем его от сервера (Detach Volume в правом меню), и удаляем его (Delete Volume). он нам не нужен.
4. Делаем снапшот для EBS диска нужного для переноса сервера (В разделе Volumes, щелкаем правой кнопкой на нужном EBS диске и нажимаем Create Snapshot). Процесс создания снапшота можно смотреть в разделе Snapshot. У меня, для диска 30 гб, процесс занимает около пяти минут.
5. Создаём новый EBS диск в нужной зоне для нового сервера из сделанного свежего снапшота. (Щёлкаем правой мышкой по нужному снапшоту, выбираем Create Volume from Snapshot). Нужно выбрать новую нужную новую Availability Zone.
6. Останавливаем текущий EC2 инстанс, (Instances, щёлкаем правой кнопкой по нужному серверу и выбираем Stop).
7. Новый EBS диск, созданный в новой зоне, нужно приатачить к новому серверу. Для этого в разделе Volume, щёлкаем правой кнопкой по нужному диску, выбираем Attach Volume и в списке выбираем наш новый инстанс. Точку монтирования нужно поменять на /dev/sda1 — т.к. это основной диск.
8. Запускаем новый EC2 инстанс в новой зоне.
9. Aссоциируем с ним elastic ip адрес (если он есть). (В разделе Elastic IP нужный Ip через пункт Associate).
10. Удаляем старый EC2 сервер и старый EBS диск.
В итоге, за 5 минут простоя, получаем сервер в нужной зоне.
Уже лет пять размещаю свои проекты на арендованных выделенных серверах. Свой отдельный сервер — это круто. Сайты всегда имеют гарантированные ресурсы, достаточно памяти, можно устанавливать любое ПО, на свой вкус и делать различные настройки. Плюс, за это время я научился администрировать Linux сервера.
Правильно сконфигурированный сервер на правильном железе может работать без сбоев несколько лет. ПО в серверных дистрибутивах Linux достаточно стабильно (я использовал раньше Debian, а сейчас Ubuntu Server). ECC оперативная память уменьшает в разы сбои в памяти, а Raid 1 или Raid 10 — позволяют пережить крах одного из серверных дисков. Читать далее
CDN — Content Delivery Network, географически распределённая сеть для ускорения доставки контента (в основном статического). По сути представляет собой, ряд серверов, в различных географических областях мира, для ускорения загрузки файлов. Т.е. если пользователь будет что-то загружать из сайта, построенного на основе CDN, то ему будут отдаваться данные с ближайшего для него сервера (ближайшего не с географической точки зрения, а с сетевой).
Услуги CDN представляют несколько компаний, я рассматриваю только Amazon CloudFront, т.к. он один из самых крупных и уже использовал раньше некоторые решения Amazon. У Amazon CloudFront всего 18 датацентров на данный момент. Из них 10 в США, 5 в Европе и 3 в Азии. Цены можно посмотреть тут: https://aws.amazon.com/cloudfront/pricing/. Что примечательно, оплата только за трафик. Т.е. если CDN не будет использоваться платить ничего не нужно (кроме 1$ снятого для проверки кредитки).
Преимущества CDN для очень крупных сайтов можно даже не перечислять, т.к. распределение работы на множество серверов там делается в первую очередь не для ускорения загрузки, а для возможности работы этих проектов в принципе и уменьшения нагрузки на сети, т.к. нет такого сервера или интернет-канала, который может выдержать, например, трафик youtube.
Для не очень больших проектов, использование CDN имеет смысл в случае большого объёма статического контента. Если сервера, например будут находиться в США, то пользователям из Европы и Азии, данные будут отдаваться гораздо медленнее. Но и внутри США CDN тоже имеет смысл использовать, т.к. это большая страна с большим количеством сетей и если сервер находится на восточном побережье, то в калифорнию сигнал идёт какое-то время.
Рассмотрим преимущества CDN для небольших проектов, для хранения статических файлов.
Ускоряется загрузка статических файлов для пользователей из разных стран мира.
Улучшается скорость загрузки сайта, что хорошо отражается на индексации и положении сайта в поисковых системах. (Скорость загрузки сайта играет определённую роль при ранжировании сайта)
Уменьшается нагрузка на сервер, т.к. статические файлы грузятся исключительно с CDN (т.е. с других серверов).
Сильно уменьшается потребление трафика на сайте, т.к. статические файлы это основной пожиратель трафика.
Минусы:
Кроме стоимости хостинга, использование СDN также стоит дополнительных денег.
Давно хотел попробовать использовать CDN для одного из проектов, но останавливало то, что нужно всё это долго настраивать. Я думал, что нужно каждый файл отправлять вручную в CDN, обновлять их, следить за целостностью кеша в CDN и т.д. — т.е. изучать API и писать много скриптов. Такой путь возможен, но оказалось всё гораздо проще.
Подключить CDN у меня заняло полтора дня. Чтобы получить доступ к Amazon CloudFront (и к другим сервисам Amazon), сначала нужно зарегистрироваться на Amazon Web Services, ввести данные своей кредитки и пройти авторизацию своего номера телефона. Через несколько минут или часов, после проверки, аккаунт будет активирован.
Затем в панели управления Amazon CloudFront нужно создать Distribution (дистрибуцию). Дистрибуция — это по сути, кеш статических файлов для отдельного сайта. Можно создать до 100 дистрибуций на аккаунт.
Первым шагом нужно указать Origin — где расположен сам сервер, на Amazon S3 либо в другом месте (Custom Origin), если отдельный сервер, нужно выбрать Custom. Затем нужно вписать название сайта, например www.mysite.com.
Во втором шаге можно указать CNAME. В принципе этот шаг не обязателен, но полезен.
После создания дистрибуции Amazon какое-то время инициализирует дистрибуцию, и даёт адрес CDN вида a1b2c3d4e5f6g7.cloudfront.net. Всё! CND работает, если на сайте, например, есть файл www.mysite.com/images/1.jpg, то его можно открыть как a1b2c3d4e5f6g7.cloudfront.net/images/1.jpg. Amazon сам скачает этот файл с сайта, распределит между своими серверами, и отдаст пользователям с ближайшего сервера, в зависимости от того, где они находятся.
Теперь насчёт CNAME. Они нужны, чтобы «спрятать» страшный урл вида a1b2c3d4e5f6g7.cloudfront.net, и чтобы безболезненно иметь возможность отказаться от CND в будущем. Для этого можно указать, например img.mysite.com и прописать его в DNS домена как CNAME с поддомена img на a1b2c3d4e5f6g7.cloudfront.net. Теперь файлы будут открываться с поддомена img.mysite.com, загружаясь на самом деле с CDN.
Для использования CDN на сайте достаточно просто поменять все ссылки на статичные файлы используя выданный адрес CDN или на указанный поддомен, в случае использования CNAME.
Остаётся только изучить Invalidate API, для экстренного удаления файлов из кеша (чтобы заменить файл более новым с сервера), но вроде есть специальные программы, скрипты, в которых это уже реализовано.
