У меня простая двухуровневая структура - один веб-сервер (Websphere, размещенный на Windows) и один сервер Oracle db. Веб-серверу необходимо подключить сервер базы данных Oracle.
Я пытаюсь написать сценарий, который
Я застрял на №3. Каждый раз, когда я запускаю скрипт, сервер БД получает другой IP-адрес. Как мне сказать моему экземпляру Websphere «Использовать этот IP-адрес для БД»?
Некоторые решения, которые я рассмотрел -
Каждое из этих решений кажется более эффективным, чем обычно. Что-то мне не хватает? Каков стандартный способ решения этой проблемы?
ИЗМЕНИТЬ для Баунти Решение с эластичным IP-адресом работает, но мне не нравится тратить зря общедоступные IP-адреса на серверах, которые никогда не должны подключаться к Интернету. Мне любопытно услышать какое-либо другое решение, которое вы использовали для решения этой проблемы.
Вы можете использовать эластичный IP-адрес, но подключитесь через его доменное имя, и он будет разрешен во внутренний адрес. Итак, очевидно, что вы получаете DNS-имя из эластичного IP-адреса, например ec2-46-147-161-187.eu-west-1.compute.amazonaws.com соответствует 46.147.161.187 в eu-west-1. Домен будет фиксированным, так что вы можете жестко его запрограммировать, если хотите.
Видеть https://forums.aws.amazon.com/message.jspa?messageID=299889.
Я бы предложил одним из решений использовать Amazon Virtual Private Cloud (VPC) - это звучит как хороший вариант использования для него. (Кроме того, в этом сценарии VPC не требует дополнительных затрат).
По сути, вы можете создать новый VPC и общедоступную подсеть (обычно 10.0.0.0/24) внутри этого VPC. Затем запустите оба экземпляра в подсеть.
PrivateIpAddress параметр с действительным IP-адресом из вашей подсети. Конечно, в этой настройке или любой настройке, не использующей NAT, каждому экземпляру, имеющему какой-либо доступ в Интернет, будет назначен общедоступный IP-адрес (даже если это не эластичный IP-адрес). Только используя частные и общедоступные подсети с экземпляром NAT, настроенным для маршрутизации, вы можете разрешить экземпляру вообще не иметь общедоступного IP-адреса, но при этом иметь доступ к Интернету. (Обратной стороной, конечно же, является то, что для небольшой настройки - например, 2 экземпляра - вам требуется 3-й экземпляр для выполнения NAT, что нецелесообразно).
Дальнейшее чтение:
Вы должны предположить, что вы не можете использовать механизм широковещательного ответа, такой как DHCP, для этого задания, что означает, что единственный оставшийся вариант - это обновить и запросить какой-либо каталог.
Динамический DNS (например, ОБНОВЛЕНИЕ DNS; RFC 2136) - очевидное решение. Если у вас уже есть сервер имен, настройка этого решения займет около 5 минут. Видеть http://linux.yyz.us/nsupdate/ для краткого руководства по настройке bind для динамических обновлений и использования nsupdate команда. Видеть эта запись в блоге для получения информации об использовании DDNS с Route 53.
В качестве альтернативы вы можете развернуть собственное решение, используя что-то вроде простого частного PHP-скрипта на каком-нибудь веб-сервере, чтобы обрабатывать обновления регистрации IP и механизмы запроса-ответа. Очевидно, что это решение немного более гибкое, но ему не хватает простой элегантности DDNS.
Вы можете настроить сервер базы данных для регистрации динамической записи DNS CNAME при запуске.
Я делаю нечто подобное для сервера, который мы назовем mydb. (имена хостов и IP-адреса были изменены для защиты личности.)
вывод из 'dig mydb.example.net' извне AWS
mydb.example.net. 108 IN CNAME ec2-123-45-6-7.compute-1.amazonaws.com.
ec2-123-45-6-7.compute-1.amazonaws.com. 258 IN A 123.45.6.7
вывод из 'dig mydb.example.net' из AWS
mydb.example.net. 108 IN CNAME ec2-123-45-6-7.compute-1.amazonaws.com.
ec2-123-45-6-7.compute-1.amazonaws.com. 258 IN A 10.2.2.2
Обратите внимание на относительно небольшой тайм-аут (108 с) для этой записи CNAME.
Когда сервер mydb запускается, он ИЗМЕНЯЕТ запись CNAME, указывая на НОВОЕ динамическое имя AWS.
Еще одна приятная вещь - это то, что в зависимости от того, находитесь ли вы вне AWS или внутри, вы получите разный ответ. (наиболее экономичный ответ)
Использование эластичного IP-адреса избавляет от необходимости ждать тайм-аута DNS TTL, так что это хорошо, но если вы можете жить с тайм-аутом DNS TTL для запуска нового сервера БД (у вас должен быть сервер БД аварийного переключения на mydb2.example.net в любом случае готовы все время, не так ли?), то это решение может сработать для вас.
Есть только три возможных решения (когда EIP не подходит), и вы, кажется, уже имеете общее представление о них:
Используйте динамический DNS. Вы можете обновить свою базу данных в зоне, размещенной в Route53, с ее частным IP-адресом. Route53 допускает очень низкие значения TTL. Ваши серверы websphere всегда должны знать, что нужно подключиться к указанному вами маршруту53 A, например mydb.internal.mydomain.com
Используйте теги, чтобы пометить роль экземпляра базы данных и IP-адрес. Затем попросите ваш сервер websphere запросить экземпляры, помеченные как сервер базы данных, и обнаружите его IP-адрес.
Используйте VPC и укажите частный IP-адрес для вашего экземпляра БД при запуске. Ваши экземпляры websphere всегда подключаются к одному и тому же назначенному ip.
Я бы избегал VPC, если в этом нет необходимости, и, учитывая ваше описание выше, это не кажется оправданным, исходя из того, что я понимаю.
Стандартный способ - использовать инструменты управления конфигурацией, такие как Chef, Puppet.
Поскольку у меня большой опыт использования Chef., Я расскажу об использовании Chef здесь.
В вашем случае так и должно быть. 1) После запуска сервера каждый сервер (иначе называемый узлом) должен зарегистрироваться на сервере Chef. 2) Каждому узлу будет назначен список запусков. Список выполнения содержит множество ролей (например, db, web и т. Д.) И / или рецептов. 3) Каждая роль будет иметь рецепты для начальной загрузки и настройки этого программного компонента.
Это более или менее похоже и в кукольном мире.
Обратите внимание, все это OpenSource. Opcode также предлагает размещенную версию Chef Server. Вы можете попробовать это.
Одна простая вещь, которую я люблю делать, - это добавлять тег на сервер.
ec2-create-tags <instance-id> --tag Purpose=DB
Затем вы можете запросить сервер на основе тега в сценарии PowerShell с помощью AWSSDKforNET. Метод New-GenericList, который у меня есть, просто создает новый список в PowerShell с использованием отражения.
$client = Create-EC2-Client
# Request a list of all the current AmazonEC2 Instances
$request = New-Object -TypeName Amazon.EC2.Model.DescribeInstancesRequest
$filterList = New-GenericList Amazon.EC2.Model.Filter
# Create a new filter to only get servers with a purpose of webserver
$filter = New-Object -TypeName Amazon.EC2.Model.Filter
$filter = $filter.WithName("tag:Purpose");
$filter = $filter.WithValue("DB");
$filterList.Add($filter);
# Add the filter to the request
$request = $request.WithFilter($filter);
$response = $client.DescribeInstances($request)
$servers = @()
foreach ($instance in $response.DescribeInstancesResult.Reservation)
{
if($instance.RunningInstance[0].InstanceState.Name -eq "running")
{
$servers += $instance.RunningInstance[0].PrivateIpAddress.ToString()
}
}
$servers
смотреть на http://www.exapark.com/product.html Этот инструмент обновляет файл hosts с текущими внутренними IP-адресами запущенных экземпляров.
Вы могли бы использовать vCider, который дает вам виртуальные частные сети даже между облачными провайдерами (так что вы можете иметь домен вещания уровня 2 в вашем центре обработки данных, например, EC2 или Rackspace). У вас также есть полный контроль над назначением IP-адресов, что означает, что у вас будет фиксированный адрес для вашего хоста. По сути, он позволяет вам создавать собственное VPC (виртуальное частное облако), но позволяет вам не зависеть от конкретных поставщиков и дает вам полную функциональность уровня 2.
Вы можете зарегистрироваться Вот. Использование до 8 хостов бесплатно. vCider также предлагает некоторые функции безопасности, которые могут вас заинтересовать.
Ах, и относительно вашей награды: вы можете использовать частные IP-адреса в своей виртуальной сети, поэтому вам не придется тратить зря общедоступные адреса или даже открывать свои серверы через общедоступный адрес. Имейте в виду, что машина EC2 всегда будет иметь общедоступный IP-адрес, но с vCider вы действительно можете сделать что-то, называемое «облачной маскировкой», которая полностью отключает весь трафик на этом общедоступном адресе, по сути, заставляя ваш хост исчезнуть из общедоступного Интернета.
Я должен упомянуть здесь, что работаю на vCider, но, пожалуйста, не позволяйте этому останавливать вас от рассмотрения vCider. Если у вас есть какие-либо вопросы, пожалуйста, дайте мне знать.