Guarire automaticamente un'istanza EC2 con un gruppo di scala automatica?

Sto provando a configurare un'istanza EC2 di autocalorizzazione utilizzando un gruppo di scala automatica e uno script di avvio dati utente. Se il server corrente ha un problema in cui non è più raggiungibile, l'istanza dovrebbe terminare e un nuovo deve sostituirsi. Questo è abbastanza facile, ma un requisito si dimostra difficile.

Ho bisogno del server di sostituzione di avere lo stesso IP privato del server precedente. Il mio pensiero è di avere un IP privato secondario (questo è all'interno di un VPC) assegnato al server originale e quindi riassegnarlo al nuovo server.

  • Più gruppi di sicurezza EC2 - permissivi o restrittivi?
  • È ansible (o efficiente) eseguire un backend completo con AWS Lambda (vs say, Elastic Beanstalk)
  • Amazon EC2 micro istanza ha 100% di utilizzo della CPU
  • Avviare automaticamente un'istanza ECE AWS dalla richiesta di networking (wake-on-LAN)
  • Come ottengo un elenco di server e il loro DNS pubblico con Amazon EC2
  • Disinstallazione non corretta dell'applicazione WSGI in AWS utilizzando Elastic Beanstalk
    1. Suppongo di poter utilizzare l'aws-cli installato durante lo script di avvio dati utente per riassegnare l'IP privato, ma come faccio a sapere quale server viene sostituito e re-assegnare l'IP da esso (ad esempio se nel futuro la piscina di server è più grande e 2 accadono di scendere contemporaneamente).

    2. Se il server originale viene terminato, potrei riuscire a assegnare nuovamente l'IP privato?

    2 Solutions collect form web for “Guarire automaticamente un'istanza EC2 con un gruppo di scala automatica?”

    Dopo molte ricerche e prove / errori, ecco cosa abbiamo finito per fare:

    1. Abbiamo messo each tipo di server nel proprio gruppo di scala automatica con uno script di shell utente per configurare completamente i server.
    2. Abbiamo utilizzato tag per tenere traccia delle risorse sui server che volevamo trasferire (IP privato, IP elastico, EBS, ecc.).
    3. Al momento dell'avvio di un'istanza di sostituzione, il nostro script di dati utente interroga l'AWS CLI per get un'istanza terminata dello stesso tipo con i tag di risorse disponibili.
    4. Utilizziamo i dati in tali tag e l'AWS CLI per assegnare tali risorse al server di sostituzione e quindi rimuovere i tag dal vecchio server.
    5. Poiché questo è tutto in un VPC, l'IP privato è ancora disponibile per noi perché viene rilasciato nuovamente alla VPC alla fine dell'istanza.

    Abbiamo funzionato per alcuni giorni e sembra funzionare abbastanza bene (anche se rimane da vedere quando un'istanza in realtà fallisce per qualcosa di diverso da noi che lo chiude direttamente per il test).

    AWS ha recentemente annunciato la funzionalità "Auto-Recovery for EC2 Instances". Per quanto lo capisco, questo funziona sostanzialmente come un gruppo di scala automatica, ma conserva IP e volumi di istanza ecc.

    Al momento questa funzionalità è disponibile solo per i casi più recenti e solo nella regione del sud-est.

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.