Pattern di progettazione del servizio condiviso della tecnologia Fujitsu K5 – Alta disponibilità

2017-01-13

Machine-translated — the English original is authoritative.

Il seguente pattern di progettazione è un esempio di come una piattaforma di servizi condivisi tecnologici potrebbe essere implementata su K5. La differenza tra questa architettura e il precedente blog sui servizi condivisi è che ho incluso i nostri connettori Inter-Availability-Zone per fornire un collegamento interno ad alta velocità tra le subnet nelle diverse Zone di Disponibilità (AZ). Ora è possibile garantire che le tue applicazioni in stile tradizionale o le app cloud native possano essere facilmente distribuite tra le due AZ. Il traffico di rete non attraversa Internet. L'intera architettura mostrata di seguito può essere distribuita automaticamente con uno sforzo minimo grazie agli stack HEAT, il progetto di orchestrazione dell'infrastruttura K5/OpenStack.

Nota per gli utenti nativi di OpenStack : Sia i collegamenti InterProject che i collegamenti InterAvailability Zone discussi qui sono miglioramenti che Fujitsu ha apportato all'API Neutron di OpenStack per l'uso nel cloud pubblico.

DMZ

Il progetto DMZ è utilizzato per instradare il traffico in entrata e in uscita dalla soluzione. Potrebbe essere utilizzato un server proxy per fornire/controllare l'accesso a Internet per gli altri progetti. Un server terminale https come Guacamole potrebbe essere installato in ogni DMZ per fornire un accesso ridondante alle console dei server.

In ogni AZ sono installati due router virtuali. Uno gestisce tutto l'instradamento inter-progetto e il secondo è utilizzato in conjunction con il FWaaS per controllare l'accesso al confine di Internet. Un'istanza LBaaS facente parte della pubblica amministrazione potrebbe essere utilizzata qui per fornire HA per il servizio Guacamole.

Servizi condivisi

Questo progetto verrebbe utilizzato per ospitare tutti i servizi condivisi che si desidera fornire ai propri progetti, come l'e-mail (anche se non dimenticare che K5 offre anche questo come offerta PaaS), la condivisione di file, i repo git, ecc. Un connettore di rete viene utilizzato per collegare le subnet dei servizi condivisi tra le zone di disponibilità, il che facilita la sincronizzazione rapida dei dati tra i servizi critici. Un LBaaS rivolto internamente potrebbe anche essere utilizzato qui se necessario. Per progettazione, queste subnet non hanno né capacità DNAT né SNAT. Sarebbe necessario sfruttare un servizio proxy nella DMZ (non parte di K5) per ottenere questo risultato. L'alternativa sarebbe collegare questa subnet direttamente a Internet tramite un altro router virtuale, rompendo il modello richiesto 🙂

Dipartimento A/B/C…ecc

Questi sono i progetti che gli utenti finali consumerebbero. Possono avere le stesse funzionalità HA esposte loro che sono nel progetto Servizi condivisi. Questo modello consente una distribuzione rapida e semplice, distruzione, ridistribuzione per soddisfare le esigenze mantenendo intatti i servizi core.

I Security Groups sono utilizzati in tutto per fornire anche un ulteriore livello di sicurezza di rete per tutti gli host.

Riepilogo

Il modello completo dei Servizi condivisi può essere distribuito rapidamente e in modo coerente più e più volte utilizzando i modelli HEAT di Infrastructure as Code (IaC) di K5. Sempre più clienti stanno sfruttando modelli come questo per aiutarli nei loro percorsi di Continuous Integration e Continuous Deployment (CI/CD). Se questo ti interessa, ti consiglio di guardare anche Cloud Foundry per lo sviluppo rapido di applicazioni: K5 offre anche una piattaforma Cloud Foundry.

Happy Stacking.

withk5youcan

Originally published on allthingscloud.eu (2017-01-13).