Modelli di Servizi Condivisi di Fujitsu K5

2016-12-01

Machine-translated — the English original is authoritative.

Nella piattaforma IaaS di Fujitsu K5 esistono molti modi diversi per implementare un'architettura di servizi condivisi a seconda delle proprie esigenze.

[Aggiornamento: 09/03/2017] : Prima di continuare, tuttavia, lasciate che vi spieghi rapidamente cosa intendo con i seguenti due termini – Control Plane e Data Plane nel contesto di OpenStack e della piattaforma IaaS K5 di Fujitsu. Immaginiamo che vi sia stato chiesto di creare un nuovo servizio Exchange per un'azienda su K5. Questo servizio richiederà i seguenti componenti infrastrutturali: una rete, un router, un firewall e un server per ospitare l'applicazione.

Control Plane, utilizzato dagli Amministratori dell'Infrastruttura K5: Per costruire questa infrastruttura avrete bisogno di accedere ai servizi del control plane di K5 – gli endpoint API che possono comunicare con i servizi Keystone, Neutron e Nova. Non è necessario che gli utenti regolari del servizio Exchange finale accedano a questo control plane.

Data Plane, utilizzato dagli utenti finali del servizio: Una volta costruita l'infrastruttura, l'amministratore di Exchange e gli utenti finali accederanno al nuovo server/servizi attraverso il data plane – essenzialmente parleranno direttamente con il nuovo server tramite la sua interfaccia virtualizzata.

Modello di Servizi Condivisi K5 – Senza Isolamento degli Utenti nel Control Plane

Il design più semplice sarebbe quello di inserire tutte le vostre istanze in un singolo progetto e utilizzare i Security Group e, opzionalmente, più subnet, per fornire un isolamento del data plane o, più correttamente, una segmentazione del traffico. Ovviamente potete comunque utilizzare i meccanismi standard di autenticazione del Sistema Operativo per controllare l'accesso alle istanze virtuali stesse.

Security Group

Uno dei componenti chiave della soluzione sopra descritta è il Security Group. Un security group in OpenStack è un meccanismo per controllare tutti i flussi di traffico in ingresso e in uscita su un'interfaccia (porta) in base all'interfaccia (porta). Un security group può contenere più regole, ciascuna delle quali definisce l'intervallo di indirizzi IP, i Protocolli e la Direzione del traffico di rete consentito. In un modello di servizi condivisi in cui il server A e il server B devono essere isolati ma entrambi possono comunicare con un terzo server C, i security group forniscono questo isolamento. È possibile anche collegare più security group a una singola interfaccia per costruire il set di regole.

Tuttavia, lo svantaggio di questo modello è che l'amministratore del progetto del control plane ha accesso a tutte le risorse.

Modello di Servizi Condivisi K5 – Con Isolamento degli Utenti sia nel Data Plane che nel Control Plane

Se desiderate garantire l'isolamento sia a livello di control plane che di data plane per le vostre risorse, questo può essere ottenuto utilizzando l'architettura sopra descritta combinata con il controllo degli accessi basato sui ruoli, più progetti e un'altra capacità di Fujitsu K5, ovvero l'Inter-Project Routing.

Controllo degli Accessi Basato sui Ruoli (RBAC)

La piattaforma Fujitsu K5 sfrutta il progetto Keystone di OpenStack per fornire il Controllo degli Accessi Basato sui Ruoli per gli utenti all'interno di un Contratto (o Domain nei termini nativi di OpenStack). È possibile definire amministratori del control plane su base progetto per progetto. Questo vi dà la capacità di distribuire le vostre risorse (macchine virtuali, reti, ecc.) su più Progetti e definire quali utenti hanno accesso amministrativo a queste risorse nel control plane.

Inter-Project Routing

Il titolo stesso lo suggerisce: questa funzionalità di K5 consente di instradare il traffico tra reti in progetti diversi all'interno dello stesso Contratto.

Combinando tutte queste capacità di K5, possiamo fornire agli Amministratori del Dominio K5 la capacità di controllare l'isolamento delle risorse sia a livello di control plane che di data plane.

Ad esempio, con il modello seguente possiamo definire un utente che può amministrare le risorse IaaS nel Progetto A e un utente diverso che può amministrare le risorse nel Progetto B. Né questi amministratori richiedono l'accesso diretto alle risorse negli altri Progetti o nel Progetto di Servizi Condivisi. Tuttavia, entrambi saranno in grado di instradare verso i servizi disponibili nel Progetto di Servizi Condivisi, purché siano state applicate le corrette Regole del Security Group.

I due modelli sopra descritti sono contenuti in una singola zona di disponibilità K5, ma questi modelli possono anche essere facilmente distribuiti tra le due zone di disponibilità utilizzando un altro componente K5 chiamato Network Connector.

K5 Network Connector

Il Network Connector ha due casi d'uso fondamentali –

• Instradare il traffico di rete dalle reti esterne dei clienti direttamente in un progetto K5.
• Instradare il traffico di rete tra reti in diverse Zone di Disponibilità all'interno dello stesso progetto.

Questo connettore evita la necessità che il traffico di rete dei clienti attraversi la connessione Internet quando si sposta tra le Zone di Disponibilità.

L'esempio seguente di uno stack LAMP illustra l'utilizzo di un Network Connector con due zone di disponibilità.

Happy Stacking!

Originally published on allthingscloud.eu (2016-12-01).