Tämä asiakirja kuvaa nykyiset vaihtoehdot sovellusten käyttöönotolle CloudHub 2.0:ssa korkean saatavuuden ja katastrofien palautuksen vaatimusten mukaisesti. Se käyttää esimerkkinä Yhdysvaltojen aluetta ja sitä voidaan soveltaa muihin alueisiin.

CloudHub 2.0 on täysin hallittu, pilvipohjainen integraatioalusta, joka välttää infrastruktuurin ylimääräiset kustannukset automatisoimalla MuleSoft API -rajapintojen ja -integraatioiden käyttöönoton, skaalautumisen ja hallinnan pilvipalveluun. Se on MuleSoftin moderni pilvitallennusalusta, joka toimii Amazon AWS -infrastruktuurilla.

Useimmissa tapauksissa CloudHub 2.0:n tarjoamat oletusarvoiset High Availability (HA)- ja Disaster Recovery (DR) -ominaisuudet riittävät. CloudHub 2.0 tarjoaa HA:n ja DR:n alueellisella tasolla (lisätietoja on kohdassa CloudHub 2.0 -poissaolojen skenaariot). CloudHub 2.0:n tärkeimmät huomioitavat asiat -osiossa on lisätietoja CloudHub 2.0:n tukemasta HA:sta ja DR:stä.

Ehtoihin, jotka vaativat CloudHub 2.0:n oletusarvoisen käytettävyyden ylittävän suunnittelun, sisältyy:

• Sovelluksen täytyy varmistaa, ettei dataa katoa katastrofi-skenaariossa (esimerkiksi Amazonin aluekohtainen kaatuminen).
• Sovellus on riippuvainen objektisäilöstä ja sen täytyy varmistaa jatkuvuus, jos käyttöönottoryhmä heikkenee.

• Taustajärjestelmät on määritetty vastaavan saatavuuden varmistamiseksi. CloudHub 2.0 voi joskus tarjota luotettavuutta jonojen tai samankaltaisten mekanismien avulla, mutta riippumatta siitä, onko integraatio reaaliaikainen vai ei-synkronoitu, taustajärjestelmien täytyy tukea vertailukelpoista HA- ja DR-tasoa.
• Kun AWS-aluetason käyttökatkos vaikuttaa taustajärjestelmiin, niiden palautuksen oletetaan tapahtuvan rinnakkain CloudHub 2.0 -palautuksen kanssa.
• Yksityisten tilojen määritykset ovat valmiita useissa alueissa.

Tämän oppaan suunnitteluvaihtoehdot keskittyvät ratkaisuihin sovellusten saatavuudelle CloudHub 2.0:ssa, kun koko AWS-käytettävyysalue tai -alue ei ole käytettävissä.

Tämä opas ei käsittele näitä palautusskenaarioita, mutta se huomaa seuraukset tarvittaessa:

• Anypoint CloudHubin ulkopuolella hallittujen ja provisioitujen taustajärjestelmien, sovellusten, tietokantojen, verkkokomponenttien ja datakeskusten palauttaminen, joko paikallisesti tai pilvipalvelimella.
• VPN-linkkien palauttaminen CloudHub 2.0:n ja asiakkaan yksityisen datakeskuksen välillä (esimerkiksi IPsec-tunnelit ja VPN-yhdyskäytävät). Jotkin tämän oppaan DR-vaihtoehdot saattavat käsitellä näitä skenaarioita osittain.
• MuleSoftiin tehdyt muutokset poistuvat IP-osoitteista katastrofien palautuksen aikana, kun IP-osoitteiden sallittujen luetteloa käytetään integraatioissa. Jotkin tämän oppaan DR-vaihtoehdot saattavat käsitellä näitä skenaarioita osittain.
• Asiakasratkaisuissa käytetyt ulkoiset viestintäjärjestelmät, olivatpa ne MuleSoftin (kuten Anypoint MQ) tai muiden toimittajien (kuten AWS MSK tai Heroku Kafka) tarjoamia.

Kun arvioit CloudHub 2.0:a katastrofien palautuksen vaatimuksille, ota huomioon seuraavat tärkeimmät asiat.

CloudHub 2.0 -riippuvuus AWS:n alueellisesta saatavuudesta

• CloudHub 2.0 toimii AWS:llä, ja sen saatavuus riippuu AWS-alueista.
• Käyttöönotot ja sovelluksen saatavuus on järjestetty alueen mukaan. Nämä alueet vastaavat AWS-alueita.

Jos koko AWS-alue epäonnistuu, sen sovellukset eivät ole käytettävissä eikä niitä replikoida automaattisesti muualle.

Sovelluksen korkean saatavuuden (HA) ja replikoinnin hallinta

• CloudHub 2.0 ottaa sovellukset automaattisesti uudelleen käyttöön samassa alueessa, kun laitteisto epäonnistuu, mutta sovellus, jolla on yksi replika, saattaa olla käyttökatkona.
• Sovellukset, joilla on useita replikoita, on otettu käyttöön oletusarvoisesti eri saatavuusvyöhykkeillä, mikä tarjoaa palvelutasoa eri vyöhykkeille.
• Jos yhden replikaatin sovelluksen saatavuusvyöhyke epäonnistuu, sovellus tuodaan automaattisesti toiseen saatavuusvyöhykkeeseen samassa alueessa.

Yhdysvaltojen Itä-alueen vaikutus

• Yhdysvaltojen Itä-alueen käyttökatkoksen tapauksessa:
  • CloudHub 2.0 -hallinnan käyttöliittymä ja käyttöönoton REST-palvelut eivät ole käytettävissä eikä uusia sovelluksia voi ottaa käyttöön.
  • Muiden alueiden sovellukset eivät muutu useimmissa virheiden skenaarioissa. Nämä sovellukset toimivat edelleen normaalisti, mutta valvonta- ja hallintaominaisuudet ohjaussuunnitelman kautta eivät ole käytettävissä käyttökatkoksen aikana.
  • Core CloudHub 2.0 -moduuleja (kuten sovellusasetuksia) säilytetään Yhdysvaltojen itäisessä osavaltiossa, joten asetuksia ei voi muokata käyttökatkoksen aikana.

Valvonta ja hälytys

• Määritä hälytys saatavuusvyöhykkeiden tai alueiden tason virheiden varalta osoitteesta status.mulesoft.com.
• Käytä erillistä terveystarkastusta ja hälytysmekannusta CloudHub 2.0:n ulkopuolella, jotta tiimit saavat ilmoituksen, jos replikat epäonnistuvat tai sovellukset eivät enää vastaa.

Datan säilytys (Objektin säiliö V2)

• Objektivarasto V2 on sidoksissa alueeseen, jossa sovellus otetaan käyttöön ensimmäisen kerran.
• Jos siirrät sovelluksen toiseen alueeseen, Object Store V2 pysyy alkuperäisessä alueessa tietojen häviämisen välttämiseksi.
• Jos alue, jossa objektisäiliö V2 on otettu käyttöön, epäonnistuu, objektisäiliö ei ole käytettävissä.

Syöttöohjaimet ja yksityiset tilat

• CloudHub 2.0:n syöttöohjaimet ovat erittäin käytettävissä aluetasolla.
• Jos yksi alue epäonnistuu jaetussa tilassa, toisen alueen syöttöohjain on edelleen käytettävissä, mutta se voi tarjota vain kyseisessä alueessa käyttöönotettuja sovelluksia.
• Jos jokin alue epäonnistuu yksityisessä tilassa, muiden alueiden syöttöohjaimet eivät ole käytettävissä, elleivät ne ole määritetty sinne etukäteen.
• Yksityisen tilan määritykset ovat alueellisia. Jos alue epäonnistuu, yksityinen tila ei ole käytettävissä, ellei toista aluetta ole määritetty.

Sovellusalustan palveluiden yleiskatsaus -alaskuvake – Objektin myymälä

High Availability (HA) on mitta järjestelmän kyvystä pysyä käytettävissä järjestelmäkomponentin virheiden varalta. Tavallisesti HA toteutetaan rakentamalla järjestelmään useita vika-toleranssitasoja ja/tai kuormituksen tasapainottamista. Se on tavallisesti Aktiivinen-aktiivinen-kokoonpano, ja se vaikuttaa vain rajoitetusti tai ei mitään liiketoimintapalveluihin.

Vahinkotapahtumien palautus (DR) on prosessi, jolla järjestelmä palautetaan edelliseen hyväksyttävään tilaan katastrofin jälkeen, joko luonnollisen (kuten tulvien, tornadojen, maanjäristysten tai tulipalojen) tai ihmisen (kuten virheiden, palvelinvirheiden tai määritysten) vuoksi. DR on tavallisesti Aktiivinen/epäaktiivinen-kokoonpano, joka vaikuttaa liiketoimintapalveluihin.

Jos haluat vähentää liiketoiminnan vaikutuksia alueellisen korkean saatavuuden tai alueellisen katastrofin palauttamisen AWS-alueen vikojen varalta, ota huomioon seuraavat asiat, kun suunnittelet ratkaisua MuleSoft CloudHub 2.0:ssa:

• CloudHub 2.0 -reseptit ja niihin liittyvät ominaisuudet — yksityiset tilat, syöttöohjaimet ja Anypoint MQ -kohteet — ovat aluekohtaisia.
• Jos koko AWS-alue epäonnistuu, kaikki alueen replikat ja niihin liittyvät palvelut eivät ole käytettävissä.
• Kun alue palautuu, kokoonpanot palautetaan. Sinun täytyy käynnistää sovellukset uudelleen.
• Jos Yhdysvaltojen Itä-alue epäonnistuu, myös Anypoint Platform -palvelut (esimerkiksi Käyttöoikeuksien hallinta ja Suorituksen aika -päällikkö) eivät ole käytettävissä.
• MuleSoft tarjoaa sovellusalustan palveluiden sopimuksen, jonka saatavuus on 99,95 % sovellusalustan palveluille, mukaan lukien alueen aktiivisessa ja aktiivisessa kokoonpanossa olevat CloudHub 2.0 -reseptit. Lisätietoja on uusimmassa MuleSoft Cloud -palvelutasosopimuksessa.
• CloudHub 2.0 ei tue usean alueen HA- tai DR-ratkaisua käyttövalmiina. Saatavuus tarjotaan vain yhdessä alueessa.

Nämä suunnittelua koskevat ohjeet pätevät riippumatta valitsemastasi määritystoiminnosta.

Monen alueen yksityisten tilojen määritykset

Kaikki seuraavissa osioissa kuvatut vaihtoehdot vaativat, että sovellukset on otettu käyttöön erillisillä alueilla. Tämä on mahdollista vain, jos yksityisen tilan määritykset on tehty etukäteen ennen katastrofia. Yksityisen tilan määritykset ovat alueellisia, joten DR-strategia vaatii vähintään kaksi yksityistä tilaa — yhden per alue — ja mekanismin, joka siirtää liikenteen sopivaan VPN-päätepisteeseen.

Yksityisen tilan määrittäminen alueen sisällä

CloudHub 2.0 ei tarjoa automaattista vahinkotapahtumaa, kun alueen yksityinen tila epäonnistuu. Väliaikainen ratkaisu on aktiivinen/passiivinen määritys useissa ympäristöissä, joka vaatii:

• Useiden VPN-yhdyskäytävien määrittäminen yksityiselle tilalle.
• Erillisten ympäristöjen luominen CloudHub 2.0 -alueelle, joilla jokaisella on oma yksityinen tilansa.
• Jonkun näistä ympäristöistä valitseminen passiiviseksi (jossa sovelluksia ei oteta alkuun käyttöön, mutta ne tuodaan esiin, jos ensisijainen yksityinen tila epäonnistuu).

Jos korkean saatavuuden määrittäminen ilman VPN-yhdyskäytävää on vaikea vaatimus, kahden alueen käyttöönotto on paras vaihtoehto. VPN-yhdyskäytävän virhe tässä skenaariossa voidaan ratkaista siirtämällä asiaankuuluva alue vaihtoehtoiseen alueeseen, jossa yksityinen tila on jo määritetty.

Null viestin häviö

Sovelluksen täytyy estää tietojen häviäminen ja korjata seuraavat seikat, jotta viestien häviäminen olisi nolla, kun koko alue epäonnistuu:

• Käytä ulkoista viestintää viestien luotettavuuden saavuttamiseksi.
• Varmista, että objektisäiliötä ei käytetä lennon aikana tapahtuville transaktioille, jotka ovat transaktioita. Jos käyttöönottokenttä, jossa MuleSoft-sovellus otettiin ensimmäistä kertaa käyttöön, ei ole käytettävissä, objektien myymälä ei ole käytettävissä.
• Pidä kaikki objektisäiliön käyttöoikeudet erillisessä kulussa tai osiossa, joka toimii edelleen — sekä poikkeusten käsittelyssä että toimintatavoissa — kun objektisäiliön luku- tai kirjoitustoiminnot epäonnistuvat.

Huomautus. Useimmissa tapauksissa DR-vaatimusten ei tarvitse varmistaa, että viesti häviää nollan onnettomuuden sattuessa ja että datan häviö on pienempi kuin tietyn ajanjakson arvo (esimerkiksi 1 tunti).

Pidä integraatio tyhjänä

Yleisenä suunnitteluperiaatteena on aina tärkeää varmistaa, että integraatiot ovat luonteeltaan tilattomia. Tämä tarkoittaa, että transaktiotietoja ei jaeta useiden asiakkaan kutsujen tai suoritusten välillä (ajoitettujen palveluiden tapauksessa). Jos jotkin tiedot täytyy ylläpitää järjestelmän rajoituksen vuoksi, ne tulisi säilyttää ulkoisessa tietokannassa, kuten tietokannassa tai viestintäjonossa, eikä MuleSoft-infrastruktuurissa tai muistissa. On tärkeää huomata, että kun skaalaudumme, varsinkin pilvipalvelussa, kunkin replikan käyttämän tilan ja resurssien tulisi olla riippumattomia muista replikoista. Tämä malli parantaa suorituskykyä, skaalattavuutta ja luotettavuutta.

Verkon ja liikenteen hallinta

• Tyhjät toimialueet ovat pakollisia alueellista saatavuutta varten. Ne toimivat globaalina DNS-palveluna kaikille alueiden syöttöjen ohjaimille.
• Globaali kuormituksen tasapainontarjoaja reitittää liikenteen ensisijaisen alueen ja DR-alueen yksityisten tilojen välillä. Asiakkaat tarjoavat tämän komponentin: käytä AWS-reititystä 53 tai globaalia CDN-verkkoa ja reitityskäytäntöjä reitittääksesi liikennettä eri alueiden välillä.
• Määritä Saapumisen ohjaimet sekä ensisijaisilla alueilla että DR-alueilla käyttämällä mukautettua tyhjätoimialuetta.
• Suunnittele ja ylläpidä palomuurisääntöjä ja VPN-tunnelua, jotta paikallisia sovelluksia voidaan käyttää sekä ensisijaisesta että DR-alueen yksityisestä tilasta.
• TLS-sertifikaattien ylläpidon täytyy kattaa sekä ensisijaisen että DR-alueen yksityiset tilat, jotta ne voidaan palauttaa saumattomasti.

Sovelluksen käyttöönotto ja kokoonpano

• Sovellusten nimien täytyy olla yksilöllisiä eri alueilla. Esimerkiksi CI/CD-putki voi liittää alueen nimen (tai alueen koodin) sovellusten nimiin ennen käyttöönottoa säilyttääkseen yksilöllisyytensä ensisijaisilla alueilla ja DR-alueilla.
• Määritä CI/CD-putki ottaaksesi sovelluksia käyttöön sekä ensisijaisille että DR-alueille, jotta kaikki sovellukset ovat käytettävissä molemmissa alueissa.

Infrastruktuuri ja kapasiteetti
Suorituskyky on paras, kun kaikilla infrastruktuurin osa-alueilla on sama ensisijainen ja DR-alueen kapasiteetti. Suorituskyky heikkenee, kun nämä infrastruktuurin osa-alueet eivät ole samoja.

Datan säilytys ja tallennus

• Pysyvän tallennustilan täytyy synkronoida säännöllisesti näiden kahden alueen välillä. Asiakkaat ovat vastuussa tallennustilan replikoinnista, mutta MuleSoft ei tarjoa sitä. Yksi jaettu tallennustila ensisijaisen alueen ja DR-alueen VPC-tuotteiden välillä on mahdollista, mutta jaetun tallennustilan täytyy olla erittäin käytettävissä, tai siitä tulee yksi virhepiste molemmille alueille.
• Objektisäiliö V2 on alueellinen ja se on käytettävissä vain alueella, jossa Mule-sovellus otettiin ensimmäistä kertaa käyttöön. Jos sovellus siirretään toiseen alueeseen, Object Store V2 pysyy alkuperäisessä alueessa tietojen häviämisen välttämiseksi. Käytä muuta pysyvää tallennustilaa usean alueen DR-strategioille.

Testit ja toimenpiteet

Ota käyttöön muodollinen DR-testistrategia ja suorita säännöllisiä DR-tarkastuksia. Jos kyseessä on aktiivinen DR, käytä kanavien käyttöönottostrategiaa vahvistaaksesi molemmat alueet.

Suorituskyky- ja palvelutasosopimukset (SLA)

Suorituskyky saattaa heikentyä, koska DR-alue saattaa olla kauempana loppukäyttäjiltä tai taustajärjestelmiltä kuin ensisijainen alue. Määritä DR SLA ja ilmoita siitä sidosryhmille.

Palautustilan toimintatapa (kontekstihuomautus)

Aktiivisessa ja aktiivisessa tilassa epäonnistuminen ensisijaisesta alueesta DR-alueen yksityiseen tilaan tapahtuu nopeasti: globaali kuormituksen tasapainottaminen havaitsee, että ensisijainen alue on epäterveellinen ja reitittää liikenteen terveelle (DR) alueelle. Aktiivinen/passiivinen-tilassa sinun täytyy ottaa sovellus käyttöön DR-alueen yksityiseen tilaan, kun katastrofi tapahtuu.

Voit saavuttaa korkeamman DR-tason saatavuuden kolmella eri tavalla:

Aktiivinen-aktiivinen kokoonpano

Aktiivinen-aktiivinen määritystoiminto perustuu aktiivisiin työntekijöihin, jotka on jaettu eri alueisiin ja jotka käyttävät ulkoista kuormituksen tasapainottamista reitittääkseen liikenteen näiden kahden esiintymän välillä.

Lämmin valmius -kokoonpano
Aktiivinen/passiivinen-määritys perustuisi aktiiviseen työntekijään yhdellä alueella ja passiiviseen työntekijään toisella alueella. Passiivinen alue -asetus käynnistettäisiin tarvittaessa.

Jotkin passiivisen alueen elementit täytyy säilyttää aktiivisina vahinkotapahtumien välttämiseksi tai ne täytyy määrittää etukäteen, mukaan lukien yksityiset tilat, VPN-yhteydet ja siirtoyhdyskäytävän liitteet.

Cold Standby -kokoonpano

Replikoiden ja syöttö-ohjaimien provisiointi tapahtuu toisella alueella täysin automatisoidun DevOps-prosessin kautta, kuten yllä on kuvattu. Jotkin passiivisen alueen elementit täytyy säilyttää aktiivisina virheenkorjausta varten, mukaan lukien yksityiset tilat, VPN-yhteydet ja kuljetusyhdyskäytävän liitteet.

CloudHub 2.0 -verkkoarkkitehtuurin peruskomponentit ovat:

• HTTP-kuormituksen tasapainottaja
• Mule replica DNS -tietueet
• Yksityiset tilat
• Alueelliset palvelut

Lisätietoja on kohdassa CloudHub 2.0 -verkkoarkkitehtuuri.

Vanity-toimialueet

Kun yksityinen tila luodaan, se saa DNS-kohteen nimen muodossa: <space-id>.<region>.cloudhub.io . Kun sovellus nimeltään test-api otetaan käyttöön kyseisessä yksityisessä tilassa, sen päätepiste noudattaa seuraavaa muotoa:

CloudHub 2.0 tukee myös mukautettuja tai turhia toimialueita määrittämällä ne yksityisessä tilassa käyttämällä TLS-konteksteja ja DNS-tietueita. Jos haluat luoda TLS-kontekstin yksityisen tilan suorituksen aikana, lataa julkinen sertifikaatti ja yksityinen avain palvelimelle ja lisää sovelluksesi asetuksiin mukautettu päätepiste toimialueen käyttämiseksi. Luo DNS-tietue (kuten CNAME), joka osoittaa turhan toimialueesi yksityisen tilasi oletusarvoiseen isäntänimeen.

Esimerkiksi sovelluksella nimeltään test-api, joka on otettu käyttöön us-west-2-järjestelmässä oletusarvoisella DNS-osoitteella 42y52r.usa-w2.cloudhub.io, API-päätepiste on:

https://test-api-mwsklu-42y52r.usa-w2.cloudhub.io

Tämä URL ei käytä turhaa tai mukautettua toimialuetta. Noudata seuraavia ohjeita käyttääksesi acme.com:ia siten, että API-osoitteet näytetään muodossa https://test-api.acme.com.

1. Luo TLS-konteksti Suorituksen aika -pääkäyttäjällä julkisilla ja yksityisillä avaimilla.
2. Lisää turhaa toimialuetta sovelluksen asetuksiin käyttääksesi kyseistä toimialuetta.
3. Luo DNS-tietue AWS-reitityksessä 53 ja määritä yksinkertainen reitityskäytäntö (esimerkiksi CNAME), jotta tyhjä toimialue palauttaa yksityisen tilan oletusarvoisen isäntänimen.

Voit käyttää mukautetuille toimialueille AWS-reititystä 53 tai muita globaaleja CDN-palveluita reitityskäytäntöjen kanssa. Alla olevassa kaaviossa AWS-reititystä 53 käytetään ”yksinkertaisen” reitityskäytännön kanssa. Kun julkisen (ulkoisen) verkoston kuluttaja pyytää acme.com:ia, AWS-reititys 53 reitittää pyynnön yksityiselle MuleSoft-tilan syöttöohjaimelle.

Käytä tätä vaihtoehtoa, kun sovellukset vaativat epäonnistumista: ota yksi esiintymä käyttöön ensisijaisessa alueessa (esimerkiksi us-west-2) ja toinen toissijaisessa alueessa (esimerkiksi us-east-1).

Käytä olemassa olevaa ympäristöä toissijaisessa alueessa aina, kun se on mahdollista. Uuden ympäristön luominen vaatii lisätoimia.

Esimerkki sovelluksista, jotka on otettu käyttöön yhdellä alueella (Yhdysvallat Länsi 2) ja jotka on ohitettu toiselle alueelle (Yhdysvallat Itä 1)

Tässä kokoonpanossa AWS-reitti 53 reitittää liikenteen Yhdysvaltojen Länsi- ja Yhdysvaltojen Itä-alueiden yksityisten tilojen syöttöohjaimille. Vahinkotapahtuman reitityskäytäntö määritetään terveystarkastuksella.

Käytä kaaviossa kuvattua käyttöönottostrategiaa vähentääksesi viiveitä ja korkean saatavuuden. Tämän strategian avulla sovelluksia voidaan ottaa käyttöön kahdella alueella (esimerkissä us-west-2 ja us-east-1).

Käytä AWS Route 53:n viiveen reitityskäytäntöä reitittääksesi pyyntöjä alueelle, joka tarjoaa vähiten viiveitä, mutta säilyttää korkean saatavuuden. AWS Route 53:n ”viiveen” reitityskäytäntö reitittää pyynnön pienemmälle viiveelle, jolla on edelleen korkea saatavuus.

Sovellukset, jotka on otettu käyttöön molemmissa alueissa (Yhdysvallat Länsi 2 ja Yhdysvallat Itä 1), vähentävät viiveitä ja parantavat saatavuutta

MuleSoft CloudHub 2.0 tarjoaa vankan perustan alueen sisäiseen kestävyyteen hyödyntämällä ensisijaisesti automatisoitua replikoiden tarpeettomuutta ja älykästä kuormituksen tasapainottamista. Sovellusten käyttöönotto yhdellä pilvialueella useilla replikoilla varmistaa, että jos yksi esiintymä epäonnistuu, muut voivat heti ottaa työnkuorman haltuunsa. Integroitu kuormituksen tasapainontarjoaja jakaa saapuvan liikenteen tehokkaasti näille terveille replikoille, mikä minimoi käyttökatkokset ja varmistaa jatkuvan palvelun saatavuuden normaaleissa toimintaolosuhteissa.

Yksinomainen riippuvuus tästä yhden alueen arkkitehtuurista, vaikka se olisi erittäin tarpeeton, aiheuttaa kuitenkin merkittävän riskin laajalle levinneelle, katastrofaaliselle alueelliselle käyttökatkokselle. Historia on osoittanut, että jopa luotettavimmat ja teknologisesti kehittyneimmät pilvipalveluntarjoajat ovat alttiita häiriötapahtumille, jotka voivat vaikuttaa koko maantieteelliseen alueeseen. Nämä yksittäiset virhepisteet, jotka ovat harvinaisia, voivat johtua useista tapahtumista, mukaan lukien:

• Suuren skaalan infrastruktuuritapahtumat
• Tärkeät virranvaihdot
• Laajat verkkohäiriöt

Jotta saavutettaisiin todellinen korkea saatavuus (HA) ja katastrofien palautus (DR), arkkitehtuuri täytyy suunnitella ylittämään yhden alueen mallin rajoitukset. Suositeltu strategia on käyttöönotto useilla maantieteellisesti erillisillä alueilla. Tämä alueiden välinen joustavuus varmistaa, että jos koko pilvialue ei ole käytettävissä odottamattoman katastrofin vuoksi, liikenne voidaan siirtää saumattomasti erilliseen, ei-vaikutettuun alueeseen suoritettavaan sovellusesiintymään, mikä takaa minimaalisen palveluhäiriön ja mahdollisimman suuren toiminta-aikojen tavoitteen saavuttamisen.

CloudHub 2.0 -verkkoarkkitehtuuri

Alueiden välisen epäonnistumisen määrittäminen vakiomuotoisille jonoille

Objektin myymälän V2 -käyttöönottoalueet

Objektin myymälän käyttöönottoryhmäsi

Gulal Kumar on Salesforcen ohjelmisto-arkkitehti, joka keskittyy dataan ja integraatioarkkitehtuuriin. Hänellä on yli 20 vuoden kokemus integroinnista ja API-rajapinnoista, modernisointiohjelmista, tietoturvasta ja AIML-aloitteista, joten hänellä on paljon ammattitaitoa. Gulal on sitoutunut edistämään liiketoiminnan transformaatio-aloitteita, parantamaan tietoturvaa ja kestävyyttä, edistämään arkkitehtuurin huippuosaamista ja johtamaan AIML-aloitteita eri toimialueissa.

Ajay Nagaraju on MuleSoftin yritysarkkitehti ja johtaja, jolla on yli 28 vuoden kokemus yritysarkkitehtuurista, järjestelmäintegraatiosta ja suuresta digitaalisesta transformaatiosta. Hän on johtanut arkkitehtuuria ja toimitusta monimutkaisille, monen miljoonan dollarin ohjelmille Fortune 100- ja Fortune 500 -organisaatioissa, ja hänellä on syvällistä asiantuntemusta API:n ohjaamien yhteyksien, SOA:n, pilviteknologioiden ja yritysten integraatiokuvioiden parissa. Ajay on tehnyt tiivistä yhteistyötä johdon kanssa liiketoimintaprosessien, datalustojen ja integraatioiden ekosysteemien modernisoimiseksi ja on intohimoinen skaalattavien arkkitehtuurien rakentamisesta, tiimien opastamisesta ja mitattavissa olevien liiketoimintatulosten edistämisestä teknologian avulla.