Domande frequenti sulla resilienza e sulla disponibilità continua dei servizi e della piattaforma Oracle Cloud Infrastructure

Dichiarazione di non responsabilità: le informazioni riportate di seguito forniscono alcune indicazioni di carattere generale in merito al prodotto. Ha esclusivamente scopo informativo e non può essere incorporato in alcun contratto. Non rappresenta un impegno nel fornire materiale, codice o funzionalità e non vi si deve fare affidamento durante le decisioni di acquisto. Lo sviluppo, il rilascio, i tempi e i prezzi di tutte le funzioni o funzionalità descritte per i prodotti Oracle possono cambiare e rimangono a esclusiva discrezione di Oracle Corporation.

Questa sezione di domande e risposte risponde a domande comuni sul modo in cui Oracle raggiunge la resilienza e la disponibilità continua dei servizi dell'infrastruttura di base e della piattaforma di hosting. I clienti di Oracle Cloud possono essere interessati a queste risposte per diversi motivi:

  • Aiutano i clienti a valutare la piattaforma di hosting e i servizi di Oracle.
  • Molte risposte descrivono sfide e soluzioni fondamentali per tutti i sistemi su scala cloud e quindi possono servire ai clienti per creare l'architettura e la progettazione dei loro sistemi nel cloud.

Domande frequenti su resilienza e disponibilità continua dei servizi e della piattaforma Oracle Cloud Infrastructure

Apri tutto Chiudi tutto
  • Oracle fa una distinzione tra classi diverse dei servizi, ad esempio servizi strategici, servizi con disponibilità continua o servizi per una singola sede?

    Non sono previste distinzioni di questo tipo. Oracle, piuttosto, suddivide i servizi in categorie in base al livello di dipendenza, all'ambito della disponibilità e al piano dati rispetto al piano di controllo. Queste categorie hanno lo scopo di fornire vari pro e contro utili a livello di disponibilità, durabilità, prestazioni e praticità.

    Livelli dipendenza

    Questi livelli potrebbero essere considerati separazioni logiche (layer) o unità di distribuzione (tier) in un diagramma a blocchi a livello di architettura. Ogni layer può dipendere solo da quelli presenti sotto di esso.

    Dal basso verso l'alto:

    • Servizi di base: questi servizi costituiscono la base di Oracle Cloud Infrastructure. Include IAM (Identity and Access Management), Gestione chiavi, Networking, Computazione, Volumi a blocchi, Storage degli oggetti, Telemetria e diversi servizi interni condivisi. Sono stati progettati per avere dipendenze minime, perfino tra di loro. Per i dettagli relativi alle dipendenze, consulta le pagine successive di questo documento.
    • IaaS: questo layer fornisce più funzionalità a livello di infrastruttura basate sul core. I servizi in questo layer sono: File Storage, Database e Container Engine for Kubernetes.
    • SaaS: si tratta di un layer software sotto forma di servizio avanzato creato sui layer inferiori.

    Ambito disponibilità

    Per raggiungere gli obiettivi in termini di disponibilità e durabilità di un servizio, viene scelto uno degli ambiti di disponibilità seguenti per ogni servizio:

    • Servizio locale del dominio di disponibilità: ogni dominio di disponibilità contiene un'istanza indipendente del servizio. Tali servizi offrono elevata durabilità dei dati memorizzati utilizzando la replica sincrona tra le repliche all'interno dello stesso dominio di disponibilità (per i dettagli, consultare la sezione relativa ai domini di errore più avanti in questo documento). Possono tollerare un'indisponibilità pari ad almeno un terzo dell'infrastruttura nel dominio di disponibilità, a seconda della natura del servizio. I servizi locali del dominio di disponibilità raggiungono questo livello di tolleranza agli errori utilizzando due tipi diversi di data center logico (gruppi logici di isolamento degli errori e di isolamento delle prestazioni) all'interno del dominio di disponibilità. Per i dettagli, consulta le sezioni relative ai domini di errore e alle celle del servizio più avanti in questo documento. Infine, questi servizi possono continuare a funzionare normalmente anche se il dominio di disponibilità non riesce a comunicare con altri domini di disponibilità. Di conseguenza, tollerano la perdita di altri domini di disponibilità o il guasto completo della rete WAN (Wide Area Network) all'interno dell'area.
    • Diversi domini di disponibilità regionali: Ogni region con più domini di disponibilità contiene un'istanza indipendente del servizio, con componenti situati in ogni dominio di disponibilità della region. Questi servizi offrono durabilità estremamente elevata dei dati memorizzati utilizzando la replica sincrona in più domini di disponibilità nella stessa area. Possono tollerare l'indisponibilità di ogni singolo dominio di disponibilità presente nell'area o l'impossibilità di comunicare con tali domini.
    • Singolo dominio di disponibilità regionale: Se una region contiene un solo dominio di disponibilità, le caratteristiche osservabili di un servizio regionale corrispondono a quelle di un servizio locale del dominio di disponibilità, come descritto in precedenza. La distinzione tra un servizio locale del dominio di disponibilità e un servizio regionale di un un singolo dominio di disponibilità diventa pertinente solo quando un'area con un singolo dominio di disponibilità si estende attraverso l'aggiunta di uno o più domini di disponibilità. Quando si verifica questa condizione, ogni servizio regionale si espande automaticamente per utilizzare in modo appropriato i nuovi domini di disponibilità, anche se continua a esserci una singola istanza del servizio. Ad esempio, il piano dati dello storage degli oggetti si espande per utilizzare i domini di disponibilità aggiuntivi e migliorare la durata dei dati esistenti. Invece, per quanto riguarda i servizi locali del dominio di disponibilità, ognuno dei nuovi domini di disponibilità riceve la propria istanza nuova e separata di ciascun servizio locale del dominio di disponibilità.
    • Distribuito tra le varie region: un principio essenziale di Oracle Cloud Infrastructure riguarda l'indipendenza operativa di ogni region rispetto alle altre region, per quanto possibile. Per quanto possibile indica che le region devono necessariamente condividere almeno un'infrastruttura, ad esempio, la rete backbone intraregionale. In caso contrario, noi non creiamo meccanismi di accoppiamento diretto tra le region, quali l'alta disponibilità o il failover trasparente, che potrebbero creare problemi su più region contemporaneamente. Al contrario, offriamo due meccanismi dedicati alla distribuzione dei servizi in tutte le region con accoppiamento indiretto:
      • Disaster recovery (DR): consentire ai nostri clienti di realizzare sistemi con caratteristiche DR è il caposaldo dell'approccio e degli investimenti che abbiamo effettuato nel cloud. Diversi servizi di base già offrono meccanismi DR, ad esempio il backup intraregionale dei volumi a blocchi e la copia intraregionale dello storage degli oggetti. Tutti e quattro i servizi dispongono della funzionalità DR come elemento ad alta priorità nella rispettiva roadmap.
      • Sottoscrizioni intraregionali: al momento, offriamo sottoscrizioni intraregionali per i dati IAM. Da un punto di vista concettuale, i dati IAM hanno un ambito globale. I clienti possono effettuare la sottoscrizione (opt-in) a un set di region e noi replichiamo automaticamente i dati IAM pertinenti e i successivi aggiornamenti nelle region specificate. Per evitare l'accoppiamento diretto, la replica è asincrona e in definitiva coerente. I clienti eseguono modifiche ai loro dati IAM in una region "home" da loro indicata. Se l'attuale region home diventa non disponibile o non adatta per qualche motivo, è possibile indicare una region diversa.

    Differenza tra piano di controllo e piano dati

    Il piano dati di un servizio è la raccolta di interfacce e componenti di elaborazione dati che implementano la funzionalità del servizio che le applicazioni dovranno usare. Ad esempio, il piano dati della rete cloud virtuale (VCN) include il sistema di elaborazione a pacchetti di rete, i router virtualizzati e i gateway, mentre il piano dati dei volumi a blocchi comprende l'implementazione del protocollo iSCSI e il sistema di storage replicato basato sugli errori per i dati del volume.

    Il piano di controllo di un servizio è il set di API e componenti responsabile dei seguenti task:

    • Gestione delle richieste dei clienti relative a provisioning, riconfigurazione, scale-up/down o arresto delle risorse
    • Rilevamento di risorse non riuscite, di qualità inferiore o configurate in modo errato
    • Rilevamento di risorse non riuscite, di qualità inferiore o configurate in modo errato
    • Esecuzione della riparazione automatica o del paging verso operatori reali per assistenza
    • Collaborazione con altri piani di controllo (ad esempio i piani di computazione, VCN, storage a blocchi vengono associati durante LaunchInstance)
    • Gestione della capacità inutilizzata
    • Coordinamento con operatori reali, ad esempio all'arrivo di nuove apparecchiature e per le attività fisiche di riparazione e manutenzione
    • Visibilità e controllo sulle operazioni
  • In che modo Oracle verifica che i servizi siano resilienti e costantemente disponibili?

  • Nelle Oracle Region contenenti più domini di disponibilità, tutti i servizi strategici sono distribuiti nei domini di disponibilità?

  • Quali sono le procedure per evitare che Oracle e i suoi clienti abbiano a disposizione un servizio strategico che dipende da un singolo data center logico?

  • Come vengono svolte le attività di manutenzione da parte di Oracle evitando che i clienti incorrano nella temporanea indisponibilità del servizio strategico?

  • I servizi di piattaforma serverless vengono implementati su più data center logici per aumentare la disponibilità?

  • Se la resilienza non è la configurazione predefinita, ai clienti viene offerta la possibilità di scegliere una distribuzione basata su più data center logici (ad esempio, una configurazione con più domini di disponibilità o intraregionale)?

  • In che modo Oracle aiuta i clienti a evitare il guasto correlato delle applicazioni causato dalle dipendenze interne tra i vari servizi dell'infrastruttura e della piattaforma?

  • I servizi Oracle Cloud Infrastructure in una region, inclusi endpoint delle API regionali, continuano a operare se isolati dalle funzioni dei piani di controllo globali?

  • I servizi Oracle Cloud Infrastructure in un data center logico continuano a funzionare se isolati dalle funzioni del piano di controllo regionale?

  • Le region Oracle Cloud Infrastructure hanno connessioni Internet ridondanti per l'alta disponibilità?