В Provisioned они как-им-то образом гарантируют уровень IOPS ± 10%, а обычный EBS может быть и лучше и хуже по производительности, зависит от нагруженности, размеров диска, погоды и кто еще знает чего. Насколько я понял из других статей EBS шарится между инстансами, от этого и скорость разная. Если взять диск 1TB то тогда можно будет достичь максимальной скорости в 1Gb, так как он полностью будет ваш.
К сожалению, о том, что на самом деле стоит за сервисами Amazon приходиться только догадываться, вычислять экспериментальным путем, тестами или узнавать случайно из общение с их поддержкой.
Puppet клиент висит и с какой-то периодичностью опрашивает мастер хост на наличие изменений? Не будет ли ситуации когда большое количество клиентов одновременно запросят изменения и положат сервер? Или, к примеру, если нужно обновить несколько серверов одновременно или в определенной последовательности, не дожидаясь пока клиенты сработают, есть подобный механизм управления?
Если есть каике-то замечения по поводу статьи, что в ней не так, чего не хватает и так далее, милости прошу освещать это в комментариях. Критика должна быть конструктивной.
Насколько я вижу естьвозможность копирования только с внешнего MySQL, а на внешний нельзя. В таком случае остается только придумывать что-то типа MySQL RDS -> S3 -> ext MySQL.
Зачем статья?
Затем чтобы люди, которые интересуются компанией EPAM и читают её блог на хабре, знали, что теперь эта компания является официальным консалтинг партнёром. К нам обращается большое количество людей за консультациями относительно размещения проектов на Amazon или по вопросам архитектуры проектов на Amazon.
Зачем нужно партнерство?
Доступ к дополнительным возможностям Amazon AWS, специализированые тренинги и семинары, которые Amazon проводит для партнёров, дополнительная поддержка.
И первая, и вторая причина помогают привлечь компании новых клиентов и новые проекты.
Он не полностью совместим с CentOS. Например клиент для Chef не устанавливается из rbel репозитория из-за несоместимости библиотек и друого софта. В Amazon Linux есть поддержка Puppet, но Chef нет в старднартном репозитории. У нас для автоконфигурации используется Chef и пришлось пока отказатьcя от использования Amazon Linux.
Да, вы конечно правы, с сервисами Amazon часто случаются какие-то проблемы. Последние события, произошедшие 29-го июня сильно повлияли на один проект, к которому я имел отношение. Проблемы на Amazon совпали с нагрузочным тестированием и подбором оптимальных настроек для авто-масштабирования. Весь рабочий день был потрачен зря.
Довольно много популярных высоконагруженных приложений хосятся на Amazon.
Конечно, для критичных систем лучше иметь свои датацентры, своё железо, запасной генератор и тому подобное. С выделенными арендованными серверами, находящимися на площадках хостинг-провайдеров и самими датацентрами провайдеров тоже часто случаются проблемы.
И конечно же, чем проще система и чем там меньше звеньев тем она более надежна, особенно когда известно что стоит за конкретным звеном и как оно работает. В случае с Amazon много их сервисом это черная коробка и только на практике можно понять её поведение в разных ситуациях.
Но данные сервисы популярны у клиентов и привлекают их своей ценой и видимой простотой настройки, по сравнению с созданием инфраструктуры в реальном датацентре. Если клиент за это хочет платить, то нужно научиться создавать как можно стабильные системы на основе того, что предлагается.
Там на самом деле всё немного сложнее. По умолчанию пул ELB IP адресов содержит только один IP на каждую зону доступности, для которой он сконфигурирован. При увеличении сетевой нагрузки в пул добавляются дополнительные IP для обеспечения необходимой пропускной способности. IP в пуле не фиксированы и могут меняться. При DNS запросе выдается IP из пула, скорее всего по Round Robin и в соответствии доступностью зон. Сам Amazon рекомендует использовать Route 53 над ELB для устранения проблемы с изменением IP в пуле и уменьшения TTL.
А что на самом деле стоит за каждым IP адресом ELB они не раскрывают, во всяком случае, я такой информации пока не нашел.
— ELB не использует один фиксированный IP, он использует пул адресов и DNS CNAME. И для работы с ним используется соответственно не IP, а доменное имя.
— ELB может работать между зонами доступности Amazon, но только в пределах одного региона
Route 53 работает между регионами, имеет встроенную проверку состояния и работает, так же как и ваши 5 DNS серверов. А проблема кэширования на уровне DNS клиента, особенно в Windows, может быть в любом случае.
Amazon, конечно, не является единственно правильным вариантом, и имеет свои недостатки. Самому свою систему можно настроить более гибко и более точно для своих конкретных целей. Все дело в сроках реализации конкретной схемы и в стоимости. На Amazon это всё можно внедрить быстрее и это может обойтись дешевле, чем использование своих датацентров или аренда серверов.
import-module «C:\Program Files (x86)\AWS Tools\PowerShell\AWSPowerShell\AWSPowerShell.psd1»
есть еще подкаталог AWSPowerShell.
Зачем статья?
Затем чтобы люди, которые интересуются компанией EPAM и читают её блог на хабре, знали, что теперь эта компания является официальным консалтинг партнёром. К нам обращается большое количество людей за консультациями относительно размещения проектов на Amazon или по вопросам архитектуры проектов на Amazon.
Зачем нужно партнерство?
Доступ к дополнительным возможностям Amazon AWS, специализированые тренинги и семинары, которые Amazon проводит для партнёров, дополнительная поддержка.
И первая, и вторая причина помогают привлечь компании новых клиентов и новые проекты.
Довольно много популярных высоконагруженных приложений хосятся на Amazon.
Конечно, для критичных систем лучше иметь свои датацентры, своё железо, запасной генератор и тому подобное. С выделенными арендованными серверами, находящимися на площадках хостинг-провайдеров и самими датацентрами провайдеров тоже часто случаются проблемы.
И конечно же, чем проще система и чем там меньше звеньев тем она более надежна, особенно когда известно что стоит за конкретным звеном и как оно работает. В случае с Amazon много их сервисом это черная коробка и только на практике можно понять её поведение в разных ситуациях.
Но данные сервисы популярны у клиентов и привлекают их своей ценой и видимой простотой настройки, по сравнению с созданием инфраструктуры в реальном датацентре. Если клиент за это хочет платить, то нужно научиться создавать как можно стабильные системы на основе того, что предлагается.
А что на самом деле стоит за каждым IP адресом ELB они не раскрывают, во всяком случае, я такой информации пока не нашел.
— ELB может работать между зонами доступности Amazon, но только в пределах одного региона
Route 53 работает между регионами, имеет встроенную проверку состояния и работает, так же как и ваши 5 DNS серверов. А проблема кэширования на уровне DNS клиента, особенно в Windows, может быть в любом случае.
Amazon, конечно, не является единственно правильным вариантом, и имеет свои недостатки. Самому свою систему можно настроить более гибко и более точно для своих конкретных целей. Все дело в сроках реализации конкретной схемы и в стоимости. На Amazon это всё можно внедрить быстрее и это может обойтись дешевле, чем использование своих датацентров или аренда серверов.