Eu tenho um arranjo simples de 2 camadas - um servidor web (Websphere hospedado no windows) e um servidor oracle db. O servidor da web precisa conectar o servidor de banco de dados oracle.
Estou tentando escrever um script que
Estou preso em # 3. Toda vez que executo o script, o servidor de banco de dados recebe um endereço IP diferente. Como eu digo à minha instância do Websphere "Usar este endereço IP para o banco de dados"?
Algumas soluções que considerei -
Cada uma dessas soluções parece mais trabalho do que o habitual. Há algo que estou perdendo? Qual é a maneira padrão de resolver este problema?
EDITAR por Recompensa A solução Elastic IP Address funciona, mas não gosto de usar o desperdício de endereços IP em servidores que nunca devem se conectar à Internet. Estou curioso para ouvir qualquer outra solução que você tenha empregado para resolver este problema.
Você pode usar um Elastic IP, mas conectar-se por meio do nome de domínio, e ele será resolvido para o endereço interno. Então, obviamente, você obtém o nome DNS do IP elástico, por exemplo, ec2-46-147-161-187.eu-west-1.compute.amazonaws.com corresponde a 46.147.161.187 em eu-oeste-1. O domínio será corrigido para que você possa codificá-lo, se desejar.
Veja o link .
Você tem que assumir que você não pode usar um mecanismo de transmissão-resposta como DHCP para este trabalho, o que significa que a única opção que resta é atualizar e consultar algum diretório em algum lugar.
O DNS dinâmico (por exemplo, DNS UPDATE; RFC 2136 ) é uma solução óbvia. Se você já tem um servidor de nomes, esta solução leva cerca de 5 minutos para ser configurada. Consulte o link para um tutorial de início rápido sobre como configurar bind para atualizações dinâmicas e usando o comando nsupdate . Veja esta entrada de blog para informações sobre o uso de DDNS com o Route 53.
Como alternativa, você pode aplicar sua própria solução usando algo como um script PHP privado simples em um servidor da web em algum lugar para lidar com atualizações de registro de IP e mecanismos de resposta de consulta. Obviamente, esta solução é um pouco mais flexível, mas falta a elegância simples do DDNS.
Eu sugiro que uma solução é usar o Virtual Private Cloud (VPC) da Amazon - isso soa como um bom caso de uso para ele. (Além disso, o VPC não tem custo adicional, neste cenário).
Essencialmente, você pode criar uma nova VPC e uma sub-rede pública (normalmente 10.0.0.0/24) dentro dessa VPC. Em seguida, inicie ambas as instâncias na sub-rede.
PrivateIpAddress com um endereço IP válido da sua sub-rede.
Naturalmente, nesta configuração ou em qualquer configuração que não utilize o NAT, cada instância que tiver qualquer tipo de acesso à Internet receberá um IP público (mesmo que não seja um endereço IP elástico). Somente usando sub-redes públicas e privadas com uma instância NAT configurada para roteamento, é possível permitir que uma instância não tenha nenhum IP público, mas ainda possa acessar a Internet. (A desvantagem é que, para uma configuração pequena - por exemplo, 2 instâncias - você precisa de uma terceira instância para realizar NAT, o que não é prático).
Leitura adicional:
Você pode fazer com que o servidor de banco de dados registre um registro DNS CNAME dinâmico na inicialização.
Eu faço algo semelhante para um servidor que chamaremos de mydb. (nomes de host e IPs foram alterados para proteger as identidades.)
saída de 'dig mydb.example.net' de fora da 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
saída de 'dig mydb.example.net' de dentro da 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
Observe o tempo limite relativamente baixo (108s) para esse registro CNAME.
Quando o servidor mydb aparece, ALTERA o registro CNAME para apontar para o novo nome dinâmico da AWS.
Outra coisa legal é que, dependendo de você estar fora ou dentro da AWS, você terá uma resposta diferente. (a resposta mais rentável)
Usar um Elastic IP ignora a necessidade de esperar pelo tempo limite de TTL do DNS, o que é bom, mas se você puder viver com um tempo limite de TTL do DNS para abrir um novo servidor de banco de dados (você deve ter um servidor de failover em mydb2). example.net pronto o tempo todo de qualquer maneira, certo?), então esta solução pode funcionar para você.
Existem apenas três soluções possíveis (quando o EIP não é uma opção) e você já parece ter controle geral sobre elas:
Use dns dinâmicos. Você pode fazer com que seu banco de dados atualize uma zona hospedada no Route53 com seu endereço IP privado. O Route53 permitirá TTLs muito baixos. Seus servidores websphere sempre devem saber se conectar à sua rota designada53 Um registro, por exemplo mydb.internal.mydomain.com
Use tags para marcar sua função de instância de banco de dados e endereço IP. Em seguida, solicite a consulta do seu servidor websphere para instâncias marcadas como um servidor de banco de dados e descubra seu endereço IP
Use um VPC e especifique o IP privado para sua instância de banco de dados no lançamento. Suas instâncias do websphere sempre se conectam ao mesmo ip designado.
Eu evitaria um VPC se não fosse necessário e, dada sua descrição acima, não parece justificável pelo que entendi.
A maneira padrão é usar ferramentas de gerenciamento de configuração como Chef, Puppet.
Desde então, eu tenho muita experiência em usar o Chef., vou falar sobre o uso do Chef aqui.
No seu caso, é assim que deve ser. 1) Após a inicialização do servidor, cada servidor (também chamado de nó) deve registrar-se no servidor chef. 2) Cada nó receberá uma lista de execução. Uma lista de execução contém muitas funções (por exemplo: db, web, etc) e / ou receitas. 3) Cada função terá receitas para inicializar e configurar esse componente de software.
É mais ou menos semelhante no mundo dos fantoches também.
Note que todos esses são OpenSource. O Opcode também oferece uma versão hospedada do Chef Server. Você poderia tentar isso.
Uma coisa simples que gosto de fazer é adicionar uma tag ao servidor
ec2-create-tags <instance-id> --tag Purpose=DB
Em seguida, você pode consultar o servidor com base na tag em um script do powershell usando o AWSSDKforNET. O método New-GenericList eu apenas criei uma nova lista no powershell usando reflexão.
$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
Você pode usar o vCider , que oferece redes privadas virtuais, mesmo em provedores de nuvem (para que você possa ter um domínio de broadcast da camada 2 seu data center, EC2 ou Rackspace, por exemplo). Você também tem controle total sobre a atribuição de endereços IP, o que significa que você terá um endereço fixo para o seu host. Basicamente, ele permite que você crie sua própria VPC (virtual private cloud), mas mantém você independente de provedores específicos e fornece a funcionalidade completa da camada 2.
Você pode inscrever-se aqui . O uso de até 8 hosts é gratuito. O vCider também oferece alguns recursos de segurança nos quais você pode estar interessado.
Ah, e quanto à sua recompensa: você pode usar endereços IP privados em sua rede virtual, para não precisar desperdiçar endereços públicos ou expor seus servidores por meio de um endereço público. Esteja ciente de que uma máquina EC2 sempre terá um endereço IP público, mas com o vCider você pode fazer algo chamado 'cloaking na nuvem', que desliga completamente todo o tráfego naquele endereço público, essencialmente fazendo com que seu host desapareça da Internet pública. / p>
Eu devo mencionar aqui que eu trabalho para o vCider, mas por favor não deixe que isso o impeça de considerar o vCider. Se você tiver alguma dúvida, por favor me avise.