1 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Экономим немного трафика на сервере в Amazon EC2

Содержание

Запускаем эластичный Windows-сервер в облаке Amazon EC2

Рис. 1. Выбираем подходящий Amazon Machine Image

Рис. 2. Настраиваем параметры микроэкземпляра

Рис. 3. При останове сервера эфемерные данные безвозвратно удалятся

Рис. 4. Задаём размеры EBS-диска

Рис. 5. При удалении сервера EBS-данные могут пропасть

Рис. 6. Настраиваем удалённое соединение

Рис. 7. Запущенный сервер функционирует нормально

Рис. 8. Выявлены проблемы при старте сервера

Рис. 9. Наглядная нагрузочная статистика

Рис. 10. Подключение к виртуальному серверу

Рис. 11. Настройка групп безопасности

Рис. 12. Задаём эластичный IP-адрес

Самая популярная услуга облаков Amazon — это конечно же возможность запуска виртуальных серверов (классическая модель IaaS). Соответствующий сервис Amazon называется Elastic Compute Cloud (EC2). Обратите внимание на слово elastic: оно применяется ко многим услугам Amazon, и “эластичность” в этой компании считается, видимо, одним из ключевых характеристик облачной системы. Похожие сервисы давно предоставляются абсолютным большинством хостеров в формате так называемых Virtual Private Server (VPS), и с точки зрения конечного пользователя отличие облачных (эластичных) машин от VPS состоит прежде всего в возможности динамически регулировать мощность виртуального сервера и быстро запускать множество серверных копий. Это позволяет быстро и незаметно для пользователей адаптировать систему к меняющимся нагрузкам (причём процессы адаптации можно автоматизировать) и значительно экономить на системе в целом. Существенное отличие облачных сервисов от VPS проявляется и в бизнес-модели: оплачивать надо не фиксированную ежемесячную сумму, а только реально использованные услуги. Так, если сервер в течение месяца работал только один час, то и оплачивать потребуется лишь 60 минут.

Формируем виртуальный сервер Amazon

Создание виртуального сервера (так называемого Instance) выполняется типовым образом из консоли AWS. В разделе EC2 нажимаем единственную кнопку Launch Instance (рис. 1) и далее выбираем подходящую ОС из обширного списка десятков исходно подготовленных дистрибутивов Amazon Machine Image (AMI).

Почти половину из этого списка занимают версии Windows Server 2008/2012, остальное приходится на различные дистрибутивы Linux. Немалое количество ОС доступно и в бесплатном формате — они помечены надписью Free tier eligible. Правда, подобные микроэкземпляры в практических проектах использовать почти невозможно в силу ограниченности предоставляемых ресурсов, однако для ознакомления, разработки и создания тестовых прототипов они вполне удовлетворительны.

Выбираем подходящую версию AMI, при необходимости задаём разрядность 32/64 и нажимаем Select. Для Microsoft Windows Server 2008 R2 с СУБД SQL Server Express и веб-сервером IIS будет предоставлен условный однопроцессорный сервер с примерной вычислительной мощностью Opteron/Xeon 2007 1 ГГц (это так называемая ECU — типовая вычислительная единица EC2), ОЗУ 612 Мб и низкой сетевой производительностью, дабы амазоновский трафик не расходовался зря (рис. 2). Важный и принципиальный момент — это предоставление хранилища данных в формате Elastic Block Store (EBS), его надо рассмотреть особо.

Храним данные на эластичных дисках

Существенное отличие облачных экземпляров ОС от классических виртуальных серверов VPS — это фактическое отсутствие долговременного хранилища данных. Если при покупке VPS-сервиса пользователь сразу получает, например, 10 Гб дискового пространства и всё, что туда будет записано, сохранится, то данные, которые размещены в облачной машине EC2 и на первый взгляд выглядят как расположенные на стабильном жёстком диске, на самом деле размещаются в её локальном кэше (так называемом эфемерном хранилище, ephemeral storage). В случае любого технического сбоя, профилактических перегрузок серверов Amazon или даже после ручного останова виртуального сервера все данные локального кэша будут стёрты, включая все настройки установленных пользователем программ (рис. 3). Точнее, прежний рабочий образ сервера будет безвозвратно удалён, а вместо него автоматически сформируется новый.

В первые годы работы Amazon эта специфика реализации модели IaaS нередко приводила к конфликтам, и в итоге Amazon запустил услугу эластичного хранилища EBS, содержимое которого не удаляется при остановке сервера. Одно время EBS-данные ликвидировались после полного удаления сервера, однако и этот режим вызывал недовольство, и сегодня по умолчанию EBS-содержимое остаётся нетронутым. Более того, можно подключать к работающим серверам новые EBS-диски, а также динамически менять их размер. Самое главное: все прикладные настройки, документы и базы данных необходимо хранить не на системном диске, а на виртуальном EBS-устройстве.

С учётом специфики работы эластичных дисков при необходимости выполним дополнительные настройки (рис. 4): например, увеличим дисковое пространство EBS, по умолчанию предоставляемое в объёме 30 Гб. Возможно, лучше отключить режим ликвидации этого хранилища при удалении виртуальной машины (рис. 5).

Разбираемся с паролями

В финальном окне создания виртуальной машины по нажатии на кнопку Launch сервис EC2 потребует загрузки файла приватного ключа — он требуется, чтобы обеспечить защищённое взаимодействие с облаком AWS, хранящим открытый ключ. Приватный ключ понадобится также при задании пароля доступа к Windows или организации SSH-взаимодействия с Linux. Если такой ключ ранее не был создан, в верхнем выпадающем списке надо выбрать пункт Create a new pair key, в поле ввода указать подходящее имя ключа и нажать кнопку Download Key Pair. Ключ сгенерируется за несколько секунд, после чего будет предложено записать его на локальный диск в файл с расширением .pem. Этот файл в дальнейшем надо аккуратно хранить. И наконец после нажатия на кнопку Launch Instance виртуальная машина EC2 создастся и запустится — этот процесс займёт считанные секунды.

Запускаем сервер EC2

Рассмотрим рабочее подключение к виртуальной машине на примере взаимодействия с Windows Server — это самый простой способ для большинства потенциальных пользователей Amazon. Список всех виртуальных серверов доступен из консоли EC2 через пункт Instances. Выберем нужную машину и нажмём кнопку Connect над списком для формирования первичного подключения. Будет предложено скачать RDP-клиент для удалённого подсоединения к виртуальному серверу (рис. 6). Нажатие на кнопку Get Password сформирует пароль для RDP-подключения (логин по умолчанию Administrator). Процесс этот небыстрый и может занять десятки минут. Кроме того, сама возможность генерации пароля будет доступна скорее всего через довольно длительный временной промежуток (10—15 минут) после запуска виртуальной машины. Пароль и IP-адрес (Public IP) сервера необходимо записать для дальнейших настроек.

Далее экземпляр сервера надо запустить, если он ещё не работает. Для этого в локальном меню сервера выбирается пункт Start. Придётся подождать, когда ОС запустится, это займёт относительно короткое время. Когда сервер будет функционировать в нормальном режиме, в пункте Instance State загорится зелёная лампочка running. Кроме того, необходимо, чтобы в столбце Status Check появилась запись “2/2 checks passed” с такой же зелёной подсветкой (рис. 7).

Не исключено, что виртуальный сервер при старте может “зависнуть” — в таком случае длительное время будет выводиться сообщение “1/2 checks passed” с жёлтой лампочкой, и доступ к паролю при этом также будет закрыт (рис. 8). У меня подобный “зависший” запуск однажды тянулся сутки, и так и не дождавшись успешного завершения процесса, я просто перезапустил сервер. По отзывам, в таких случаях служба поддержки Amazon реагирует не слишком оперативно, однако эта скорость зависит от выбранного тарифного плана.

Процесс запуска можно контролировать просмотром системного лога, получаемого выбором пункта Get System Log локального меню виртуального экземпляра. Сервер будет готов к эксплуатации, когда в этом логе появится сообщение “Windows is Ready to use”.

В главной консоли EC2 выводится довольно подробная разноплановая статистика по текущей загрузке серверов (рис. 9). Отмечу, что такая полезная возможность предоставляется далеко не всеми VPS-провайдерами. Кроме того, доступна бета-версия утилиты AWS Diagnostics for Microsoft Windows Server, которая позволяет вести детальный анализ проблемных настроек и умеет, например, выявлять конфликты между межсетевым экраном Windows и группами безопасности Amazon.

Удалённо подключаемся к серверу

Подключение к серверу с помощью удалённого рабочего стола выполняется типовым способом: достаточно ввести IP-адрес сервера, стандартный логин Administrator и пароль. Amazon также предлагает загрузить уже готовую настройку для запуска клиента удалённого стола. Надо отметить, что в различных версиях Windows могут возникать проблемы с доступом к экземпляру Amazon по протоколу RDP, даже если к виртуальным серверам других провайдеров RDP-доступ выполняется успешно. В таких случаях можно порекомендовать независимые RDP-клиенты — например, 2X Client. Как видно из картинки (рис. 10), подключение к Windows Server 2008 прошло успешно, запущен также SQL Server и веб-сервер. Теперь в браузере можно набрать IP-адрес виртуального сервера (ранее сохранённый Public IP), и он покажет стандартную пригласительную страничку IIS 7.

После настройки машины и сохранения данных на EBS-диске можно сделать собственный образ AMI и зарегистрировать его в Amazon, что позволит в дальнейшем быстро “поднимать” множество однотипных серверов за считанные минуты.

Задаём политики безопасности

В ряде случаев для доступа к серверу Amazon может дополнительно потребоваться настройка групп безопасности, определяющих, в частности, способы доступа к портам сервера по различным протоколам. Эта настройка выполняется выбором в локальном меню сервера пункта Change Security Groups и заданием правил доступа для входящих (Inbound) и исходящих (Outbound) запросов (рис. 11). Для начального тестирования можно указать возможность обращения ко всем портам без ограничений, но в дальнейшем эти правила надо будет тщательно отрегулировать. Назначение созданных или модифицированных групп безопасности для сервера выполняется через пункт Security Groups главного меню консоли EC2.

Читать еще:  Обзор фитнес-браслета Fitbug Orb: маленький персональный тренер

Настраиваем эластичный IP

После каждого останова или перезапуска сервера его IP-адрес будет меняться, что существенно усложняет организацию к нему постоянного доступа. Так, переброс DNS-имени на новый IP-адрес занимает подчас сутки, за это время можно растерять множество пользователей и сильно упасть в рейтинге поисковых машин, а то и вовсе пропасть из них. Однако привычную концепцию статического IP-адреса Amazon не поддерживает, предлагая вместо него услугу Elastic IPs. Она подразумевает предоставление статического IP-адреса, который привязывается не к серверу, а к пользователю (логину). Такой эластичный IP можно перебросить на другой, заранее подготовленный виртуальный экземпляр (или даже сетевой пул) за несколько минут, практически незаметно для клиентов. Подобная, несколько странная на первый взгляд для пользователей VPS-серверов услуга как раз и реализует облачную elastic-концепцию. Понадобилось перевести свой проект на новые ресурсы? Готовим новый сервер и бесшовно переводим на него пользователей.

Получение эластичного IP выполняется выбором пункта Elastic IPs консоли EC2 и нажатием кнопки Allocate New Address. Привязка созданного эластичного IP к экземпляру сервера осуществляется с помощью кнопки Associate Address и выбором нужного сервера (рис. 12). В дальнейшем переброс эластичного IP с машины на машину происходит с помощью кнопок Associate Address и Dissociate Address.

Разбираемся с ценами

Плата за использование серверов EC2 взимается за каждый час их работы. При этом сервер считается работающим, даже если он остановлен. Чтобы деньги за фактический простой не списывались, сервер надо удалять (команда Terminate локального меню), а если требуется часто использовать собственную оригинальную конфигурацию, следует сформировать AIM-образ для быстрого развёртывания серверов.

Первый год в рамках бесплатного тарифного варианта пользователю EC2 ежемесячно предоставляется 750 часов работы серверных экземпляров Linux и Windows, 750 часов балансировщика нагрузки ELB, 30 Гб пространства EBS, 1 Гб под хранение архивного образа диска (Snapshot) для возможного создания AIM и 15 Гб суммарного исходящего трафика. Однако в дальнейшем самый дешёвый платный вариант с хостингом на Windows (1 ECU, 1,7 Гб ОЗУ и диск 160 Гб), включая SQL Server, обойдётся в весьма приличную сумму — 0,625 долл. в час или 460 долл. в месяц. За такие деньги можно арендовать физический dedicate-сервер со схожими характеристиками, размещённый в ЦОДе провайдера, с удобством эксплуатации которого, конечно, виртуальные серверы пока не сравнятся. Следует учитывать и особенности эксплуатации Windows: например, если отказаться от SQL Server, то цена снизится до 0,091 долл. в час (вероятно, дело в стоимости лицензии на СУБД). А вот виртуальный сервер на базе Red Hat Linux с такими же техническими характеристиками стоит в пять раз дешевле.

Кроме того, можно существенно экономить, оплачивая облачный хостинг на длительный срок. Соответствующий режим эксплуатации называется Reserved Instances. Например, в случае с Windows Server резервация потребует всего 0,033 долл. в час, но только если заплатить всю сумму на годы вперёд.

Как сэкономить на Amazon EC2

Содержание статьи

Достаточно часто случается так, что затраты на хостинг проекта больше, чем все прочие расходы на его содержание. Особенно это касается тех проектов, которые активно используют Amazon AWS. Но далеко не все знают, что Amazon предоставляет различные средства для того, чтобы позволить своим клиентам платить за пользование сервисами AWS меньше.

Что такое Auto Scaling и как он работает

Auto Scaling — это технология от Amazon, которая позволяет увеличивать/уменьшать количество твоих инстансов в EC2 в зависимости от заданных тобой условий: нагрузки на инстансы, объема трафика и прочего. Таким образом, ты всегда сможешь быть уверен в том, что твой проект будет продолжать свою работу даже при резком росте трафика, а в случае минимального количества посетителей ни один цент не будет потрачен впустую на оплату неиспользуемых мощностей.

Итак, основные преимущества использования Auto Scaling заключаются в следующем:

  • Меньше вреда от некорректно работающего инстанса. Auto Scaling может определять неисправный инстанс, удалять его и запускать новый на замену удаленному.
  • Схема работы проекта будет более отказоустойчивой. Auto Scaling можно сконфигурировать на использование нескольких подсетей или Availability Zones. Таким образом, если одна подсеть или Availability Zone станет недоступна, Auto Scaling начнет создавать инстансы в другой для того, чтобы проект был доступен извне.
  • Увеличение и уменьшение количества используемых инстансов по мере необходимости. Немаловажен тот факт, что плата за использование Auto Scaling не взимается, ты платишь лишь за те инстансы EC2, которые были запущены.

Как вообще работает Auto Scaling? Типовой пример изображен на рисунке.

Пример Auto Scaling

Хакер #190. Что скрывает Tor?

Мы начинаем с Auto Scaling Group, у которой желаемое количество инстансов выставлено в 2. Происходит событие на добавление инстансов в Auto Scaling Group. В рамках этого события Auto Scaling получает инструкции на запуск нового инстанса. Данное событие может либо быть запланированным согласно расписанию, либо возникать по результатам срабатываний CloudWatch-событий. После этого новый инстанс создается, конфигурируется и добавляется в Auto Scaling Group. Процедура инициации удаления инстанса происходит точно так же — она срабатывает либо по расписанию, либо на основе метрик CloudWatch.

Углубление в детали

С услугой Auto Scaling тесно связаны такие три понятия, как Groups, Launch Configurations и Scaling Plans. Разберем их подробнее.

В Auto Scaling Groups объединяются инстансы, выполняющие одинаковые функции (например, только www-инстансы или только MySQL) с целью управления ими и увеличением/уменьшением их количества. То есть если твоему приложению для достижения максимальной производительности необходимо увеличить количество инстансов того или иного типа, это делается в настройках соответствующей Auto Scaling группы. Ты можешь делать это вручную, а можешь задать некоторый набор условий, согласно которым инстансы будут добавляться/удаляться, и тогда количество запущенных инстансов будет регулироваться автоматически. Как уже упоминалось выше, Auto Scaling умеет проверять «здоровье» каждого инстанса. Если, по мнению Auto Scaling, инстанс из какой-либо Auto Scaling группы окажется «нездоров», то он будет уничтожен и будет создан новый инстанс ему на замену.

Launch Configuration — это совокупность параметров (таких как ID образа, тип инстанса, SSH-ключи, группы безопасности и маппинг блочных устройств), однозначно описывающих конфигурацию инстанса, который необходимо создавать при использовании данной Launch Configuration. Когда ты создаешь Auto Scaling группу, тебе необходимо связать ее с одной из существующих Launch Configuration. Достаточно важный момент: Launch Configuration нельзя изменять после создания. То есть если тебе необходимы новые инстансы с какими-то новыми параметрами (например, переделанный AMI), то необходимо создать новую Launch Configuration. После чего ты указываешь новую Launch Configuration в настройках Auto Scaling группы, и новые инстансы будут создаваться с новыми настройками. Старые инстансы изменены не будут.

А с помощью Scaling Plan можно указать Auto Scaling, при каких условиях нужно создавать дополнительные инстансы / удалять лишние существующие.

Использование Auto Scaling

Не стоит думать, будто использование Auto Scaling для проекта — это еще один шаг в сторону увольнения штатного системного администратора :). На самом деле есть и специфичные для Auto Scaling’a проблемы. Вот часть из тех, с которыми мы столкнулись:

  1. Чересчур долгие периоды удаления старых записей из ARP-кеша у тех инстансов, которые взаимодействуют с Auto Scaling инстансами. Значения по умолчанию были для нас слишком велики. Выражалось это в итоге вот в чем: Auto Scaling инстанс с IP 10.0.1.100 был удален двадцать минут назад. В ARP-кеше на MySQL-сервере осталась запись, где IP 10.0.1.100 однозначно привязан к некоторому MAC-адресу. Пять минут назад был создан новый Auto Scaling инстанс с IP 10.0.1.100, но с другим MAC-адресом. Догадываешься, что получилось в итоге? Правильно, из-за того, что ARP-кеш на MySQL-сервере своевременно не обновился, у нас отсутствовала связь между www и MySQL — так как с MySQL-сервера пакеты уходили на старый MAC-адрес. Решилось это правкой настроек, уменьшением тайм-аутов на очистку ARP-кеша, но ситуация все равно была неприятная.
  2. Время создания автоскейлов должно быть минимальным. В этом очень сильно помогает создание Launch Configuration на базе преконфигуренного AMI. Из нашей практики: на достаточно крупных проектах имеет смысл создавать AMI, которые будут содержать не только соответствующим образом настроенное ПО, но и последнюю ревизию кода. Это позволит Auto Scaling инстансу принимать и обрабатывать запросы от посетителей буквально сразу же после загрузки операционной системы. Если же время создания автоскейла достаточно велико и занимает порядка пяти-десяти минут, то это может негативно сказаться на производительности проекта. Особенно когда только что стартовала рекламная кампания клиента, которая дала поток посетителей, втрое превышающий норму на этот день недели и это время.
  3. Точная настройка условий, при которых будет создан новый Auto Scaling инстанс. В первое время работы с Amazon Auto Scaling мы столкнулись с проблемой: выяснялось, что созданные нами условия, по которым Amazon определял необходимость создания новых автоскейлов, хоть и выглядят верными, но на самом деле далеки от реальности. Мы не учитывали, сколько времени уходит на создание одного инстанса, за какое время нагрузка на существующие инстансы прыгала от «выше среднего» до «сверхвысокая», и еще некоторые мелкие детали. В результате — шлифовка корректных условий для Auto Scaling заняла у нас несколько дней.

Эти проблемы были самыми основными. Порой случаются мелкие, но досадные казусы, например, недавно не сразу смогли собрать новый AMI с некоторыми изменениями из-за проблем на стороне API Amazon, что задержало выкладку новой версии продукта в production.

При использовании Auto Scaling достаточно важным остается такой момент, как мониторинг всего и вся на созданных автоскейлах. Причем крайне важно, чтобы инстансы подключались к мониторингу автоматически сразу после создания: при высоких величинах посещаемости проекта за день может быть создано/удалено порядка нескольких десятков автоскейлов, добавлять их все в мониторинг вручную будет сложновато. Мониторинг важен по одной простой причине: периодически новый автоскейл создается некорректно. Код отрабатывает с ошибками, коннекты по нужным адресам не проходят. В таких ситуациях сразу после обнаружения подобных инстансов необходимо исключить их из Load Balanсer’a для того, чтобы запросы посетителей не отправлялись на них.

Типовая схема применения Auto Scaling

Как выглядит обычный проект, чья инфраструктура полностью состоит из сервисов Amazon? В качестве DNS-серверов для основных доменов используется Amazon Route 53. Это отказоустойчивый DNS-сервер от Amazon, который обладает очень полезными функциями. Все инстансы общаются между собой только по внутренним IP-адресам, чтобы трафик ходил только внутри дата-центров Amazon. Инстансы с MySQL, memcached, Redis, MongoDB и прочими — обычного типа. Инстансы, на которых выполняется код проекта (обрабатываются запросы посетителей), состоят в Auto Scaling группе. При различных изменениях величины входящего трафика от пользователей проекта соответствующим образом меняется и количество www-автоскейлов, что позволяет выдерживать любую нагрузку.

Читать еще:  Светлое будущее. Часть 2

Заключение

Автоматизация работы системного администратора всегда была актуальной задачей. Сначала это были bash-скрипты, потом уровень вырос до применения инструментов, автоматизирующих настройку серверов, таких как Puppet/Chef/CfEngine, сейчас же появляется новый уровень — автоматизация управления железом серверов.

Да, в данном случае железо виртуальное, но сейчас есть возможность создания виртуальных серверов, которые могут быть мощнее, чем многие из существующих физических. Amazon Auto Scaling — яркий пример технологии, которая позволяет в автоматизированном режиме управлять количеством серверов, задействованных в работе вашего проекта, с помощью достаточно удобного и гибкого интерфейса. Также не стоит забывать, что именно с помощью Auto Scaling ваша организация сможет сэкономить тысячи долларов на оплате хостинга проекта — это тоже достаточно немаловажный фактор.

До встречи! Увидимся, когда будем разговаривать еще об одной технологии, помогающей сделать нашу жизнь лучше :).

Растолкуйте по Amazon EC2

Народ, кто пользовался Amazon EC2, растолкуйте. Там вроде можно год на халяву пользоваться, только я что-то не пойму, халява — только в американском облаке, Европа — за деньги? Дальше, вот я пытаюсь создать инстанс, выбираю образ (AMI), всевозможных AMI — несколько сотен, какой выбрать? И наконец, чтобы подключиться к VPS удалённо мне же внешний IP понадобится, он — тоже бесплатно на год или за него платить нужно?

Внешний IP для подключения не нужен. Ssh’ишься на их точку входа, а она по ключу тебя узнаёт и перекидывает, куда надо.

То есть там ssh-прокси? А что с выбором AMI?

Там образы должны быть помечены «eligible for the free tier». Скорее всего, тебя предупредят, что ты выходишь за рамки free tier. Но, как всегда, гарантий нет.

Ох уж эти нищеброды. Ну заплатишь пару долларов по ошибке — велика проблема.

Я в итоге заплатил, не помню из-за чего. Вроде был еще лимит, чтоб 10гб диска не перебрать.

Да дело не в нищебродстве, дело в том что я интерфейс Amazon EC2 пока до конца не понял. Все эти AMI, Instance, Volume и прочие специфические термины. Вот если взять не облачный, а обычный хостинг, предоставляющий VDS, FistVDS например, там при заказе VDS предлагается конечное число готовых образов не более 10, самые популярные дистрибутивы. В Amazon EC2 же образов более сотни. Я так понимаю AMI — это что-то большее чем просто образ виртуальной машины, это какая-то специфическая амазоновская фича?

AMI это специфичный для амазона образ виртувльной машины

Пользовался год (24/7 включен), за бесплатные пределы не выходил, только я создавал на hdd вместо ssd, чтобы на всякий случай по iops не было лимита. Образы смотри лучше официальные, я юзал дебиан 7. В целом доволен полностью, цена/качество вне конкуренции 😉

Ещё можно зарегать на левые данные и одноразовую карту, вроде есть истории успеха.

Экономим немного трафика на сервере в Amazon EC2

Продолжим эксперименты с нашим сервером в облаке Amazon EC2. Для тех, кто не понял, о чём сейчас речь, надо для начала прочитать две (первую и вторую) предыдущие статьи. Некоторые моменты, подробно описанные ранее, будут опущены. Если сомневаетесь, не забыли ли чего, ещё раз перечитайте уже опубликованные материалы. В этой же заметке будет рассказано о том, как немного сэкономить трафик, а заодно и некоторое количество нервов при работе с нашим сервером в облаке Amazon EC2. Но для начала надо решить, так ли уж необходимы эти дополнительные настройки. Ситуация двоякая. С одной стороны, Amazon EC2, как и любой порядочный облачный сервис, считает буквально каждый чих пользователя. То есть внимательно следит за потреблением каждого из ресурсов сервера, которые в нашем случае вовсе не бесконечны. В первую очередь это ограничения по объёму передаваемого трафика, а заодно и количество дисковых операций. Остальные ресурсы выдаются с гораздо большим запасом. С другой стороны, трудно предсказать, сколько именно трафика удастся сэкономить. Легко может получиться так, что затраченные усилия будут превышать потенциальную выгоду. Так что решать вам.

Каким образом можно уменьшить потребление трафика? В нашем случае простейшим вариантом будет установка прокси-сервера. А точнее, сразу двух — кеширующего и сжимающего. Работать мы будем исключительно с данными, передаваемыми по протоколу HTTP и 80-му порту. Во-первых, именно такой трафик превалирует при работе в Сети. Во-вторых, кешировать или сжимать другие данные (например, мультимедиа) в нашем случае либо бессмысленно, либо накладно. В-третьих, далеко не все программы могут корректно работать даже через прозрачные прокси. Недостатком такого метода будет небольшое увеличение задержки при открытии сайтов, а также тот факт, что некоторые особо въедливые веб-сервисы не допускают до «царского тела» посетителей, которые используют прокси.

Впрочем, в нашем случае можно достаточно гибко настроить всю эту систему. Например, полностью отказаться от кеширующего прокси. Или сделать так, чтобы при подключении через IP-over-DNS трафик проходил через цепочку прокси (хотя бы через сжимающий), а в случае с обычным VPN (PPTP) — шёл напрямую. Также цепочка прокси может оказаться полезной, если у вас медленное подключение к Сети или используется помегабайтная оплата трафика. В качестве кеширующего прокси мы будем использовать классику жанра, а именно Squid. Для сжатия же вполне подойдёт Ziproxy. Таким образом, схема подключения к Сети будет выглядеть так: Веб-браузер ↔ Ziproxy ↔ Squid ↔ Интернет. Вся остальная информация будет пускаться в обход цепочки прокси-серверов.

⇡#Настройка Squid

Сначала установим и настроим Squid. Для этого в PuTTY откроем консоль удалённого сервера и введём команду

и тут же на всякий случай остановим его демон

Теперь надо сделать резервную копию исходного конфигурационного файла командой

Всё, можно приступать непосредственно к настройке прокси-сервера:

Файл конфигурации Squid — это такая огромная «портянка» сплошного текста весом под 200 килобайт. По настройке этого прокси-сервера можно написать целую диссертацию, а для освещения всех вопросов тонкого тюнинга Squid потребуется научный труд в трёх томах. Если говорить серьёзно, то ничего страшного в этом объёмистом файле нет. Процентов девяносто в нём занимают подробные комментарии с примерами к каждому описываемому параметру. В нашем случае будет достаточно немножко отредактировать стандартный (рекомендованный) файл конфигурации Squid, внеся в него пару изменений.

Squid базируется на так называемых списках контроля доступа (ACL — Access Control List). Описание каждого списка начинается с директивы acl, потом идёт название списка, затем тип и значение. К спискам применяются правила доступа, например http_access. Каждое правило начинается с названия типа, затем указывается действие (например, запрет или разрешение), его параметры и объект (список или что-то другое), к которому оно применяется. Есть также просто параметры, такие как http_port. Все списки, правила, параметры считываются и применяются в том порядке, в котором они записаны. Поэтому сначала прописываются разрешающие правила, а потом запрещается всё остальное. Вот такая сложная на первый взгляд, а на самом деле довольно простая идеология.

По умолчанию доступ к Squid по HTTP разрешён только с той машины, на которую он установлен. Чтобы исправить это, надо добавить строку «http_access allow localnet» перед строкой «http_access deny all». Таким образом мы разрешили доступ к серверу с IP, которые входят в список localnet. Так как мы знаем, что соединяться с сервером мы будем через PPTP или IP-over-DNS, то можно отредактировать этот список, внеся в него только нужные нам подсети и закомментировав (убрав) ненужные:

Делать это необязательно, можно обойтись стандартной конфигурацией. А вот следующий параметр надо обязательно поправить:

Это указание серверу, на каком интерфейсе и порту принимать запросы от пользователей, а также указание его типа. В нашем случае это будет IP 127.0.0.1 (доступ только с локальной машины), порт 8080, тип — прозрачный (transparent). Если вы не планируете использовать перед кеширующим прокси сервер Ziproxy, то этот параметр лучше привести к такому виду:

Также после установки и отладки Squid полезно заменить строку

Это отключит ведение лога Squid, а значит, не будет расходоваться лимит на операции ввода-вывода, хотя с точки зрения безопасности это не самый лучший вариант. В конце статьи будет дана ссылка на архив с готовыми конфигурационными файлами из нашего примера и инструкция по копированию их на сервер. Если же вы всё-таки решили самостоятельно отредактировать файл в nano, то вот маленький совет. Для поиска нужной директивы нажмите Ctrl+W, введите TAG: имя_директивы (например, TAG: http_port) и нажмите Enter. Останется только промотать вниз описание соответствующего параметра и внести изменения. Не забудьте сохранить файл после редактирования. Если будет желание и уверенность в своих силах, то можно поискать в Сети инструкции по тонкой настройке кеша Squid и попробовать его настроить. Только делать это надо осторожно.

⇡#Настройка Ziproxy

Ziproxy получает запрос от клиента, запрашивает данные у нужного сайта, получает их, «на лету» сжимает в Gzip и уже в заархивированном виде передаёт обратно. Практически все современные браузеры поддерживают сжатие Gzip. Устанавливаем и сразу же останавливаем демон Ziproxy, а заодно и сохраняем исходный файл настроек:

Отредактировать конфигурационный файл можно привычной командой

Настройки нужно привести к примерно такому виду (здесь, как и ранее, дается укороченная версия файла, без комментариев и прочего «мусора»):

Разберём некоторые параметры. В Port указывается номер порта, на котором будут приниматься запросы. В NextProxy и NextPort заносится IP-адрес и порт вышестоящего прокси-сервера. В нашем примере это Squid (см. опцию http_port). Если не планируется использовать Squid или любой другой прокси после Ziproxy, то эти строчки надо закомментировать (поставить # в начале). Следующие две опции лучше не трогать. ZiproxyTimeout — это время ожидания ответа от удалённого сервера в секундах. Этот параметр можно не менять или уменьшить, например до 60 секунд. Вряд ли сервер, не ответивший через минуту, ответит через полторы. В MaxSize указывается максимальный размер обрабатываемого файла в байтах. Можно поэкспериментировать с его значением, но тут есть одна особенность. Если сильно уменьшить этот параметр, то сервер начнёт пропускать без сжатия небольшие файлы вроде картинок. Если переборщить, то увеличится время ожидания, так как Ziproxy придётся сначала выкачать весь файл, пережать его и уже потом отдать клиенту.

Следующие три параметра оставляем в покое и переходим к Process*. Из названия пунктов понятно, что серверу разрешено сжимать, а что нет. ProcessHTML* — экспериментальная опция. Если вёрстка страниц будет «ломаться», то её надо будет отключить. В ImageQuality указывается в процентах качество изображений JPG и PNG от лучшего к худшему, до которого они будут сжиматься. К статье также будет приложен этот файл настроек, но вы можете отредактировать его и вручную. Выше приведены только базовые опции сжатия трафика. В Ziproxy есть ряд экспериментальных функций, которые можно включить. Но они не всегда корректно и стабильно работают.

Читать еще:  Обзор новых возможностей Adobe Creative Cloud

Сохраняем файл после редактирования и запускаем прокси:

Если потом надо будет что-нибудь поправить в настройках, то не забывайте после этого перезапускать демоны:

⇡#Настройка маршрутизации

Надо сделать так, чтобы все запросы на 80-й порт шли через прокси-сервера, а остальные данные пропускались мимо:

Можно по-разному настроить маршрутизацию. Если мы хотим, чтобы трафик не сжимался, то вместо порта 3128 указываем 8080 (см. выше нужную настройку Squid для этого случая). 192.168.244.0 и 172.16.15.0 — это подсети для соединений VPN и IP-over-DNS из предыдущих статей. Если, к примеру, нет желания использовать прокси-цепочку при подключении через PPTP, то тогда пропускаем первые две строчки. Также не забываем добавить и сохранить эти строки в /etc/rc.local командой

Если впоследствии надо будет подкорректировать настройки маршрутизации, то придётся удалить соответствующие строки из /etc/rc.local и выполнить следующие команды:

⇡#Заливка файлов на сервер

Скачиваем программу WinSCP, устанавливаем и запускаем её. Жмём справа на кнопку New и попадаем в диалог настройки нового соединения. В поле Host name указываем DynDNS-имя сервера (в нашем примере это был amazec2.dyndns-ip.com), Port number оставляем равным 22, в User name вбиваем ubuntu, в Private key file выбираем наш файл ppk-ключа. Protocol настраиваем, как на скриншоте ниже. Теперь жмём Save, выбираем любое имя для нашего соединения, сохраняем его и жмём Login.

Скачиваем архив с примерами конфигурационных файлов, распаковываем и копируем их в папку /home/ubuntu/ на удалённом сервере. В консоли выполняем следующие команды:

Переходим к разделу «Настройка маршрутизации» (см. выше) и выполняем предложенные инструкции. Всё, прокси-сервера готовы к работе. Попробуйте поработать в таком режиме. Если что-то будет не устраивать, то можно подкрутить настройки, как в примерах выше. В крайнем случае можно избавиться от Squid и Ziproxy командами

⇡#Вместо постскриптума

В ходе работы с сервером выявилась одна маленькая неприятность — журнал авторизации (/var/log/auth.log) за пару дней успел вырасти до каких-то неимоверных размеров. При беглом осмотре журнала нарисовалась вот такая картина:

Какие-то бодрые товарищи пытались банальным брутфорсом (перебором логинов и паролей) получить доступ к SSH. Не то чтобы это редкая ситуация, напротив, подобное встречается сплошь и рядом. Однако удивила настойчивость этих товарищей и, скажем так, недальновидность. Нам-то ничего особенно не грозит, так как авторизация происходит в SSH с помощью ключа. Но факт всё равно неприятный. Много трафика они не отъели, однако из-за ошибок авторизации возросло количество записей в соответствующий файл, а значит и число операций с диском. Чтобы избежать подобных ситуаций в будущем, достаточно выполнить пару несложных действий:

Прости и прощай Amazon AWS EC2

Около года тому назад я создал VPS сервер на Amazon AWS EC2. Теперь после завершения сотрудничества с этим сервисом хотелось бы в двух словах поделиться впечатлениями о работе с ним.

Так сказать, подвести итог.

Как всё начиналось и закончилось

В начале 2016 года меня полностью перестали устраивать возможности виртуального хостинга. Особенно в свете того, что большинство провайдеров, предоставляющих данный вид услуг очень любят устанавливать различные лимиты даже для «безлимитных» платных аккаунтов. При том, что алгоритмы расчётов для этих лимитов как правило окутаны завесой тайны.

Согласитесь, что заплатить деньги (иногда не малые) и потом думать не отключат ли ваш сайт на неопределённый период времени якобы за превышение чего-нибудь не самое приятное удовольствие. Поэтому я решил перейти на VPS. Всё-таки возможности последнего ограничены лишь ресурсами, которые выделены для виртуальной машины.

После изучения целого ряда предложений мой выбор пал на Amazon. И 26 мая 2016 года был запущен VPS сервер, на котором длительное время пребывал этот сайт. Данный сервер был остановлен и удалён 8 мая 2017 года вместе с аккаунтом Amazon после переезда к другому хостинг провайдеру.

Что понравилось

Первое, что понравилось и на что я собственно соблазнился, так это длительный тестовый период (1 год), который сервер отработал практически без проблем.

Высокое качество образов операционных систем. Без доработок от «чудоспециалистов» и вытекающих из этого сюрпризов.

Высокий, почти 100% аптайм без каких-либо ухищрений по части администрирования. Это относится как к самим серверам, так и к ПО устанавливаемому на них.

Что не понравилось

Очень сложный процесс регистрации. О нём уже немало написано в интернете. Потому не стану останавливаться на нём подробно.

Одним из основных факторов, который спровоцировал моё решение уйти с Amazon AWS стала финансовая политика компании.

Amazon производит все расчёты за услуги AWS в долларах США независимо от региона вашего проживания. Поэтому стоимость аналогичных серверных мощностей у Amazon вполне может оказаться несопоставимо выше, чем у большинства региональных хостинг-провайдеров.

Другое неприятное следствие этого – затраты на услуги Amazon AWS не всегда возможно спрогнозировать из-за колебаний курса.

Вторым таким фактором послужили условия оплаты. Использование любых сервисов Amazon AWS требует привязки банковской карты. По окончании тестового периода (если он предусмотрен для используемого сервиса) или превышении лимитов, выделенных для тестового пользования деньги с этой карты будут автоматически списываться (Источник).

Здесь ключевое слово – автоматически. «Обычный» хостинг провайдер за свои услуги как минимум выставит счёт.

Сам процесс работы с Amazon AWS также вызывает ряд вопросов.

Довольно сложный и неочевидный процесс развёртывания и настройки. В частности, для того чтобы ваш web сервер смог полноценно работать необходимо самостоятельно получить и прикрепить к нему выделенный IP адрес (Elastic IP) и открыть соответствующие порты при помощи Security Group.

Для сравнения большинство провайдеров предоставляют 1 выделенный IP адрес автоматически вместе с сервером. А, о необходимости открытия вручную того же 80 порта даже речи не идёт.

В целом за почти год работы сложилось впечатление, что даже такой сервис как EC2 ориентирован в основном на работу внутри инфраструктуры Amazon.

Web интерфейс неудобный и «тормозит».

Отсутствует возможность «переустановки» операционной системы на сервере. Почему-то требуется создавать полностью новую виртуальную машину и после этого удалить старую со всеми вытекающими из этого перенастройками привязок и т.д.

Также насколько мне известно, у Amazon AWS нет специальных услуг по администрированию. Поэтому, если вы далеки от IT сферы и у вас под рукой нет компетентного системного администратора, этот хостинг провайдер скорее всего не для вас.

Мой вердикт

Amazon AWS это безусловно сервис с высоким качеством услуг. Но пользоваться им имеет смысл по большей части корпоративному сектору (бюджеты, штат специалистов) или тем, кому нужен временный сервер для краткосрочного проекта, и кто принципиально стремится минимизировать затраты.

Возможно Amazon AWS хорошее «облако» для Enterprise. Только для частных проектов и «обычных» web разработок его использование создаёт неоправданные сложности и риски. А, следовательно, и затраты на их преодоление или нивелирование. Поэтому я решил не продлевать пользование сервером после завершения тестового периода, а поискать более выгодные предложения.

Как говорится, ничего личного.

В целом подводя итог, я не жалею, что работал Amazon AWS. За это время мной был получен ценный опыт, который мне успел пригодиться уже не один раз.

Amazon EC2 – Типы инстансов и цены

Есть несколько типов инстансов (виртуальных машин для запуска).

m1.small
1.7 Гб – оперативной памяти
1 EC2 юнит процессора
160 Гб диска
Базовая цена: $0.065 в час (

m1.medium
3,75 Гб – оперативной памяти
2 EC2 юнита процессора
410 Гб диска
Базовая цена: $0.130 в час (

m1.large
7.5 Гб – оперативной памяти
2 процессора по 2 EC2 юнита каждый
850 Гб диска
Базовая цена: $0.260 в час (190$ в месяц)

t1.micro
613 Мб – оперативной памяти
до 2 EC2 юнита процессора
160 Гб диска
Базовая цена: $0.020 в час (

c1.medium
1.7 Гб – оперативной памяти
2 процессора по 2.5 EC2 юнита каждый
350 Гб диска
Базовая цена: $0.165 в час (

Это не все типы инстансов, есть более мощные, вплоть до 117 Гб памяти, подробно про типы инстансов тут: http://aws.amazon.com/ec2/instance-types/

На размер диска смотреть не стоит, т.к. он всегда удаляется при крахе сервера или перезапуске инстанса, т.е. для виртуального хостинга (один или несколько сайтов на сервере) нужно всегда использовать EBS.

Что такое юнит процессора (EC2 compute unit)? В документации написано, что это примерно 1Ггц мощности современного Xeon/Opteron процессора. Точно информации нету, судя по выводу утилиты atop — инстанс может быть запущен на сервере с разными процессорами (я видел от 1.86 до 2.23 Ггц).

m1.small, m1.medium, m1.large — сбалансированные типы инстансов, каждый из них отличается от следующего по памяти и производительности процессора в 2 раза. Я использую сейчас m1.medium. m1.large имеют дополнительную оптимизацию работы с EBS дисками.

t1.micro — самый слабенький тип инстанса, но самый дешёвый, обеспечивает в пике до 2 EC compute unit производительности. Для меня, он просто идеален для тестирования. Например, на момент написания этого поста мой блог крутится на этом инстансе (я поставил 32-бит убунту для уменьшения потребления памяти). Также, если вы впервые регистрируетесь на Amazon и используете только t1.micro его можно использовать бесплатно в течении года. Крутое предложение, я считаю. Подробней о AWS Free Tier.

c1.medium High-CPU инстанс с повышенной мощностью процессора, чем базовые (m1) типы инстансов. Минус не очень большое кол-во оперативной памяти.

Теперь о особенностях ценовой политики Amazon EC2, тут всё очень интересно:

Если ориентироваться на базовую цену инстансов, то она не слишком привлекательна. Например m1.medium имеет чуть меньше 4 гб памяти и по сути одноядерный 2Ггц процессор. А я недавно арендовал 4-ядерный сервер с 8 Гб памяти за практически такую же цену (99$ в месяц).

То что я указал, как базовая цена — это цена on Demand, по требованию. Т.е. цена за час, если запустить любой тип инстанса. Эта цена без скидок. Кроме того есть очень хорошие скидки, есть покупать Reserved Instances (Зарезервированные инстансы). Планы Reserved Instances можно купить на 1 или на 3 года. Эта опеределённая сумма, которую нужно заплатить вперёд, но зато цена за час очень сильно снижается.

Всего есть три типа Reserved Instances — light, medium и heavy.

Я покажу расчёт цен для m1.medium типа инстанса. Для остальных типов скидки аналогичны.

Ссылка на основную публикацию
Статьи c упоминанием слов:
Adblock
detector