Dettagli fatturazione DR stack completo

Modalità di calcolo della fatturazione per una configurazione DR

Risorse membro che comportano addebiti

Full Stack DR utilizza solo pacchetti di messaggi OCPU, ECPU o OIC allocati come base per il calcolo dei costi. I costi per Full Stack DR maturano per qualsiasi membro di computazione, database o Oracle Integration di un gruppo di protezione DR, indipendentemente dal fatto che la risorsa sia in esecuzione o arrestata. Ad esempio, un'istanza di computazione non mobile che esiste nella standby region ma si trova sempre in stato arrestato fino all'esecuzione di un'operazione DR accumulerà comunque addebiti orari, anche se non è in esecuzione.

Risorse OCI che comportano addebiti

Determinazione del consumo delle risorse

La tabella riportata di seguito mostra come viene determinato il consumo delle risorse per vari tipi di risorse dei membri OCI che comportano addebiti orari per Full Stack DR. Determinare il pacchetto di messaggi OIC e il consumo del processore per la maggior parte dei tipi di risorse OCI è semplice e basato su ciò che viene visualizzato nella pagina dei dettagli per ogni singola risorsa nella console OCI. Tuttavia, alcune risorse, come alcuni database Oracle che non mostrano il consumo del processore per i singoli database, derivano dal totale aggregato della CPU consumata dal cluster VM.

Strumento di stima dei costi

Oracle offre uno strumento di stima dei costi facile da usare sulla pagina del prodotto Full Stack DR.

Full Stack Disaster Recovery non installa, configura o distribuisce risorse OCI come computazione, storage, rete, database o applicazioni. Sei responsabile della progettazione della strategia di disaster recovery che desideri orchestrare con Full Stack Disaster Recovery e sei anche responsabile della creazione, configurazione e distribuzione di tutte le risorse OCI IaaS e PaaS al di fuori del flusso di lavoro per Full Stack Disaster Recovery. Pertanto, dovresti già avere un'idea delle risorse che verranno distribuite in entrambe le aree prima di iniziare a lavorare con Full Stack Disaster Recovery. Ciò significa che è possibile utilizzare lo strumento di stima dei costi prima di aver effettivamente distribuito risorse OCI in una delle due region OCI.

Considerazioni:

L'esempio riportato di seguito mostra un sistema aziendale immaginario distribuito in due aree OCI. Ogni cliente avrà qualcosa di diverso a seconda dei servizi IaaS e PaaS che fanno parte dello stack di applicazioni. Questo esempio mostra come stimare il costo per lo spostamento solo della computazione e nessun database. In questo scenario, le risorse OCI esistono solo in una singola area in qualsiasi momento. Questo è simile all'approccio utilizzato da altri provider di servizi cloud per il disaster recovery. Questa strategia si basa sulla replica dello storage di avvio e a blocchi per ogni virtual machine nella standby region in modo da aggiungere solo il conteggio OCPU per l'area in cui le virtual machine sono attualmente in esecuzione.

Lo strumento di stima dei costi include sei campi per collegare i conteggi totali di OCPU ed ECPU per le risorse IaaS e PaaS in ogni area. La tabella seguente rappresenta i sei campi che verranno compilati nello stimatore costi. I valori nei campi si basano sui dettagli mostrati sotto la tabella che rappresenta uno stack di applicazioni di fantasia distribuito per il disaster recovery in due aree OCI.

Totale attivo di tutta la CPU utilizzata dalle istanze di computazione o dai database che sono membri del gruppo di protezione DR nell'area primaria (regione 1).

La tabella seguente mostra un esempio delle risorse IaaS e PaaS esistenti o che esisteranno nell'area principale. I totali della CPU nell'ultima riga della tabella riportata di seguito sono le cifre mostrate nella stima dei costi di esempio riportata sopra.

CPU nel gruppo di protezione DR in standby

Totale attivo di tutta la CPU utilizzata dalle istanze di computazione o dai database che sono membri del gruppo di protezione DR nella standby region (regione 2).

Questo esempio include solo lo spostamento della computazione, che esiste solo in una singola area in un dato momento. Pertanto, nel gruppo di protezione in standby non sono presenti risorse membro a pagamento, il che significa che non sono previsti costi per Full Stack Disaster Recovery nella standby region.

L'esempio riportato di seguito mostra un sistema aziendale immaginario distribuito in due aree OCI. Ogni cliente avrà qualcosa di diverso a seconda dei servizi IaaS e PaaS che fanno parte dello stack di applicazioni. Questo esempio mostra come stimare il costo per lo spostamento della computazione e di due database Oracle. In questo scenario, le risorse OCI di computazione esistono solo in una singola area, mentre i database hanno entrambi Data Guard abilitato, il che significa che ci sono risorse OCI in entrambe le aree. Questo è simile all'approccio pilot light che altri provider di servizi cloud utilizzano per il disaster recovery, tranne per il fatto che puoi includere il database come parte dello stesso recupero senza distribuire attività a team diversi. Questa strategia si basa sulla replica dello storage di avvio e a blocchi per ogni virtual machine nella standby region in modo da aggiungere solo il conteggio OCPU per l'area in cui le virtual machine sono attualmente in esecuzione. Per i database, verranno aggiunti conteggi di OCPU ed ECPU a entrambe le aree poiché sono in esecuzione risorse in entrambe le aree.

La stima dei costi include sei campi per collegare i conteggi totali di OCPU e ECPU per le risorse IaaS e PaaS in ogni area. La tabella seguente rappresenta i sei campi che verranno compilati nella stima dei costi. I valori nei campi si basano sui dettagli mostrati nella tabella riportata di seguito che rappresentano uno stack di applicazioni immaginario distribuito per il disaster recovery in due region OCI.

Totale attivo di tutta la CPU utilizzata dalle istanze di computazione o dai database che sono membri del gruppo di protezione DR nell'area primaria (regione 1).

La tabella seguente mostra un esempio delle risorse IaaS e PaaS esistenti o che esisteranno nell'area principale. I totali della CPU nell'ultima riga della tabella riportata di seguito sono le cifre mostrate nella stima dei costi di esempio riportata sopra.

Totale attivo di tutta la CPU utilizzata dalle istanze di computazione o dai database che sono membri del gruppo di protezione DR nella standby region (regione 2).

Questo esempio include solo lo spostamento della computazione, che esiste solo in una singola area in un dato momento. Pertanto, nel gruppo di protezione in standby non sono presenti risorse membro a pagamento, il che significa che non sono previsti costi per Full Stack Disaster Recovery nella standby region.

L'esempio riportato di seguito mostra un sistema aziendale immaginario distribuito in due region OCI. Ogni cliente avrà qualcosa di diverso a seconda dei servizi IaaS e PaaS che fanno parte dello stack di applicazioni.

Questo esempio illustra come determinare i prezzi di Full Stack DR quando sia la computazione in movimento che quella non in movimento e più database abilitati per Data Guard sono membri dei gruppi di protezione DR in entrambe le aree. Questo è un semplice esempio del motivo e del modo in cui è possibile utilizzare la computazione non mobile per applicazioni non Oracle e Oracle come E-Business Suite, PeopleSoft, JD Edwards EnterpriseOne e altre che non dispongono di funzionalità DR intrinseche integrate nei propri prodotti. Questi prodotti in genere richiedono che l'applicazione venga installata su macchine virtuali esistenti ed eseguite contemporaneamente in entrambe le regioni; l'applicazione viene installata in entrambe le regioni, ma non è in esecuzione nella standby region.

A scopo illustrativo, questo esempio utilizza un totale di quattro istanze di computazione:

La stima dei costi include sei campi per collegare i conteggi totali di OCPU e ECPU per le risorse IaaS e PaaS in ogni area. La tabella seguente rappresenta i sei campi che verranno compilati nella stima dei costi. I valori nei campi si basano sui dettagli mostrati nella tabella riportata di seguito che rappresentano uno stack di applicazioni immaginario distribuito per il disaster recovery in due region OCI. Si noti che non ci sono costi associati ai database installati e gestiti dagli utenti: il costo viene invece contabilizzato dall'OPCU utilizzato dalle virtual machine che ospitano il database e Data Guard.

Totale attivo di tutta la CPU utilizzata dalle istanze di computazione o dai database che sono membri del gruppo di protezione DR nell'area primaria (regione 1).

La tabella seguente mostra un esempio delle risorse IaaS e PaaS esistenti o che esisteranno nell'area principale. I totali della CPU nell'ultima riga della tabella riportata di seguito sono le cifre mostrate nella stima dei costi di esempio riportata sopra.

Totale attivo di tutta la CPU utilizzata dalle istanze di computazione o dai database che sono membri del gruppo di protezione DR nella standby region (regione 2).

Questo esempio include solo lo spostamento della computazione, che esiste solo in una singola area in un dato momento. Pertanto, nel gruppo di protezione in standby non sono presenti risorse membro a pagamento, il che significa che non sono previsti costi per Full Stack Disaster Recovery nella standby region.

Esempio 4: stack di applicazioni con OKE, database, Oracle Integration, spostamento della computazione e della computazione non mobile

L'esempio riportato di seguito mostra un sistema aziendale immaginario distribuito in due region OCI. Ogni cliente avrà qualcosa di diverso a seconda dei servizi IaaS e PaaS che fanno parte dello stack di applicazioni.

Questo esempio illustra come determinare il prezzo di Full Stack DR per un sistema aziendale che include nodi di lavoro ospitati su un cluster Oracle Kubernetes Engine (OKE) e computazione in movimento e non in movimento come membri di gruppi di protezione DR in entrambe le aree. Si tratta di un esempio su piccola scala di un'architettura di distribuzione più tipica per un sistema aziendale che potrebbe ospitare uno stack di applicazioni per qualsiasi applicazione non Oracle o Oracle per la pianificazione delle risorse, la finanza, la gestione del warehouse, la gestione della supply chain, la gestione delle relazioni con i clienti, il portale di vendita e così via. La computazione mobile può essere utilizzata per ospitare applicazioni Oracle o non Oracle che possono funzionare con modifiche minime quando viene eseguita in un'altra area. La computazione non mobile viene in genere utilizzata per ospitare applicazioni Oracle o non Oracle che non possono funzionare o che possono essere facilmente modificate per funzionare quando vengono attivate in un'area diversa. Esempi di applicazioni che potrebbero essere installate su computazione non mobile sono le applicazioni Oracle quali PeopleSoft, JD Edwards EnterpriseOne, Oracle Siebel CRM, Oracle E-Business Suite, Oracle WebLogic Server e così via. Queste applicazioni richiedono l'installazione e l'esecuzione attiva su virtual machine nell'area primaria e l'installazione, anche se non sono attive su virtual machine in esecuzione nella standby region.

A scopo illustrativo, questo esempio utilizza un totale di quattro istanze di computazione standard, quattro nodi di lavoro OKE e diversi database Oracle tra cui Autonomous Database, Base Database ed Exadata recuperati in un'unica esecuzione del piano DR:

La stima dei costi include sei campi per collegare i conteggi totali di OCPU e ECPU per le risorse IaaS e PaaS in ogni area. La tabella seguente rappresenta i sei campi che verranno compilati nella stima dei costi. I valori nei campi si basano sui dettagli mostrati nella tabella riportata di seguito che rappresentano uno stack di applicazioni immaginario distribuito per il disaster recovery in due region OCI.

Totali metriche

CPU nel gruppo di protezione DR primario

Totale attivo di tutta la CPU utilizzata dalle istanze di computazione o dai database che sono membri del gruppo di protezione DR nell'area primaria (regione 1).

La tabella seguente mostra un esempio delle risorse IaaS e PaaS esistenti o che esisteranno nell'area principale. I totali della CPU nell'ultima riga della tabella riportata di seguito sono le cifre mostrate nella stima dei costi di esempio riportata sopra.

CPU nel gruppo di protezione DR in standby

Totale attivo di tutta la CPU utilizzata dalle istanze di computazione o dai database che sono membri del gruppo di protezione DR nella standby region (regione 2).

Includi solo le risorse membro attualmente esistenti nella standby region. Non è necessario calcolare la posizione in cui le risorse esisteranno dopo un'operazione di DR, è sufficiente aggiungere le risorse in cui esistono nello stato normale corrente delle operazioni. Lo spostamento della computazione nella region primaria non è incluso come membro del gruppo di protezione DR in standby, pertanto non sono previsti costi OCPU per lo spostamento della computazione nella standby region.