Hei Habrin lukijat! Edellisessä artikkelissa puhuimme yksinkertaisesta AERODISK ENGINE -tallennusjärjestelmien katastrofipalautusmenetelmästä - replikaatiosta. Tässä artikkelissa sukeltaamme monimutkaisempaan ja mielenkiintoisempaan aiheeseen - metroklusteriin, eli kahden datakeskuksen automaattiseen katastrofisuojaustyökaluun, jonka avulla palvelinkeskukset voivat toimia aktiivisessa-aktiivisessa tilassa. Kerromme, näytämme, rikomme ja korjaamme.
Kuten tavallista, teorian alussa
Metroklusteri on klusteri, joka on jaettu useisiin paikkoihin kaupungin tai kaupunginosan sisällä. Sana "klusteri" vihjaa meille selkeästi, että kompleksi on automatisoitu, eli klusterin solmujen vaihtaminen vikojen sattuessa (failover) tapahtuu automaattisesti.
Tässä on suurin ero metroklusterin ja tavallisen replikoinnin välillä. Toiminnan automatisointi. Toisin sanoen tiettyjen tapahtumien (palvelinkeskuksen vika, kanavien rikkoutuminen jne.) sattuessa tallennusjärjestelmä suorittaa itsenäisesti tarvittavat toimenpiteet tietojen saatavuuden ylläpitämiseksi. Tavallisia replikoita käytettäessä järjestelmänvalvoja suorittaa nämä toimet kokonaan tai osittain manuaalisesti.
Mitä se tekee?
Tiettyjä metroklusteritoteutuksia käyttävien asiakkaiden päätavoite on minimoida RTO (Recovery Time Objective). Eli IT-palvelujen palautumisajan minimoimiseksi vian jälkeen. Jos käytät perinteistä replikointia, palautusaika on aina suurempi kuin palautusaika metroklusterin kanssa. Miksi? Erittäin yksinkertainen. Järjestelmänvalvojan on oltava työpaikalla ja vaihdettava replikointia manuaalisesti, kun taas metroklusteri tekee tämän automaattisesti.
Jos sinulla ei ole erityistä päivystävää järjestelmänvalvojaa, joka ei nuku, ei syö, ei tupakoi tai sairastu, mutta katsoo tallennusjärjestelmän tilaa 24 tuntia vuorokaudessa, ei ole mitään keinoa taata, että ylläpitäjä olla käytettävissä manuaaliseen vaihtoon vian aikana.
Näin ollen RTO ilman metroklusteria tai järjestelmänvalvojien päivystystason 99. tason kuolematonta ylläpitäjää on yhtä suuri kuin kaikkien järjestelmien kytkentäaikojen ja enimmäisajan summa, jonka jälkeen ylläpitäjälle taataan alkaa työskennellä tallennusjärjestelmän ja siihen liittyvien järjestelmien kanssa.
Siten tulemme siihen ilmeiseen johtopäätökseen, että metroklusteria tulisi käyttää, jos RTO:n vaatimus on minuutteja, ei tunteja tai päiviä, eli silloin, kun palvelinkeskuksen kauhistuimman kaatumisen sattuessa IT-osaston tulee tarjota yrityksellä on aikaa palauttaa pääsy IT-palveluihin minuuteissa tai jopa sekunnissa.
Miten se toimii?
Alemmalla tasolla metroklusteri käyttää synkronista tietojen replikointimekanismia, jota kuvailimme edellisessä artikkelissa (katso alla). ). Koska replikointi on synkronista, sen vaatimukset ovat asianmukaiset, tai pikemminkin:
- kuitu fysiikkana, 10 gigabitin ethernet (tai suurempi);
- palvelinkeskusten välinen etäisyys on enintään 40 kilometriä;
- optisen kanavan viive datakeskusten välillä (tallennusjärjestelmien välillä) jopa 5 millisekuntia (optimaalisesti 2).
Kaikki nämä vaatimukset ovat luonteeltaan neuvoa-antavia, eli metroklusteri toimii, vaikka nämä vaatimukset eivät täyty, mutta on ymmärrettävä, että näiden vaatimusten noudattamatta jättämisen seuraukset ovat yhtä suuria kuin molempien varastojärjestelmien toiminnan hidastuminen. metroklusterissa.
Synkronista replikaa käytetään siis tiedon siirtämiseen tallennusjärjestelmien välillä, mutta kuinka replikat vaihtuvat automaattisesti ja mikä tärkeintä, miten vältetään aivojen jakautuminen? Tätä varten yllä olevalla tasolla käytetään lisäyksikköä - välimiestä.
Miten välimies toimii ja mikä on hänen tehtävänsä?
Välimies on pieni virtuaalikone tai laitteistoklusteri, joka on käynnistettävä kolmannessa paikassa (esimerkiksi toimistossa) ja joka tarjoaa pääsyn tallennustilaan ICMP:n ja SSH:n kautta. Aloittamisen jälkeen välimiehen tulee asettaa IP ja sen jälkeen määrittää sen osoite tallennuspuolelta sekä metroklusteriin osallistuvien kauko-ohjainten osoitteet. Tämän jälkeen erotuomari on valmis lähtemään.
Tuomari tarkkailee jatkuvasti kaikkia metroklusterin tallennusjärjestelmiä, ja jos tietty tallennusjärjestelmä ei ole käytettävissä, hän päättää toiselta klusterin jäseneltä (yksi "live-tallennusjärjestelmistä") vahvistaneen epäkäytettävyyden. replikointisääntöjen ja kartoituksen vaihtaminen.
Erittäin tärkeä kohta. Välimiehen tulee aina sijaita eri paikassa kuin ne, joihin tallennusjärjestelmät sijaitsevat, eli ei DPC 1:ssä, jossa varasto 1 sijaitsee, eikä DPC 2:ssa, johon varasto 2 on asennettu.
Miksi? Koska vain tällä tavalla tuomari voi yhden säilyneen säilytysjärjestelmän avulla määrittää yksiselitteisesti ja tarkasti minkä tahansa kahdesta varastojärjestelmät asennettavasta paikasta putoamisen. Mikä tahansa muu tapa asettaa välimies voi johtaa aivojen jakautumiseen.
Sukellaan nyt välimiehen työn yksityiskohtiin.
Useita palveluita on käynnissä välimiesjärjestelmässä, joka kysyy jatkuvasti kaikkia tallennusohjaimia. Jos kyselyn tulos eroaa edellisestä (käytettävissä/ei saatavilla), se kirjoitetaan pieneen tietokantaan, joka toimii myös välimiehen kanssa.
Harkitse välimiehen logiikkaa yksityiskohtaisemmin.
Vaihe 1. Käytettävyyden määrittäminen. Tapahtuma, joka ilmoittaa tallennusjärjestelmän viasta, on se, että saman tallennusjärjestelmän molemmilta ohjaimista ei lähetetä pingiä 5 sekunnin ajan.
Vaihe 2. Vaihtoprosessin aloittaminen. Kun välimies havaitsi, että yksi tallennusjärjestelmistä ei ole käytettävissä, hän lähettää pyynnön "elävälle" tallennusjärjestelmälle varmistaakseen, että "kuollut" tallennusjärjestelmä on todella kuollut.
Saatuaan välimieheltä tällaisen komennon toinen (live) tallennusjärjestelmä tarkistaa lisäksi pudonneen ensimmäisen tallennusjärjestelmän saatavuuden ja jos ei, lähettää välimiehelle vahvistuksen hänen arvauksestaan. SHD ei todellakaan ole saatavilla.
Saatuaan tällaisen vahvistuksen välimies aloittaa etätoimenpiteen replikoinnin vaihtamiseksi ja kartoituksen nostamiseksi niille replikoille, jotka olivat aktiivisia (ensisijaisia) kaatuneessa tallennusjärjestelmässä, ja lähettää komennon toiselle tallennusjärjestelmälle muuttaa nämä replikot toissijaisista ensisijaisiksi. ja nosta kartoitus. No, toinen tallennusjärjestelmä suorittaa nämä toimenpiteet, minkä jälkeen se tarjoaa pääsyn kadonneisiin LUN:eihin itsestään.
Miksi lisävahvistus tarvitaan? Päätösvaltaisuuden vuoksi. Toisin sanoen suurimman osan klusterin jäsenten parittomasta (3) kokonaismäärästä on vahvistettava yhden klusterin solmun putoaminen. Vain silloin tämä päätös on täysin oikea. Tämä on välttämätöntä virheellisten kytkentöjen ja vastaavasti aivojen jakautumisen välttämiseksi.
Vaihe 2 vie noin 5-10 sekuntia ajassa, joten kun otetaan huomioon epäkäytettävyyden määrittämiseen tarvittava aika (5 sekuntia), 10-15 sekunnin kuluessa vian jälkeen LUN:t, joissa on pudonnut tallennusjärjestelmä, ovat automaattisesti käytettävissä työskentelyä varten live-tilassa. varastointi.
On selvää, että yhteyden katkeamisen välttämiseksi isäntien kanssa on myös huolehdittava oikeasta aikakatkaisujen asettamisesta. Suositeltu aikakatkaisu on vähintään 30 sekuntia. Tämä estää isäntäkonetta katkaisemasta yhteyttä tallennustilaan vikasietokuormituksen aikana ja voi varmistaa, ettei I/O-katkos ole.
Odota hetki, käy ilmi, että jos kaikki on kunnossa metroklusterin kanssa, miksi tarvitsemme säännöllistä replikointia?
Itse asiassa kaikki ei ole niin yksinkertaista.
Mieti metroklusterin hyviä ja huonoja puolia
Joten ymmärsimme, että metroklusterin ilmeiset edut tavanomaiseen replikointiin verrattuna ovat:
- Täysi automaatio takaa minimaalisen palautumisajan katastrofin sattuessa;
- Ja siinä se :-).
Ja nyt huomio, miinukset:
- Ratkaisun hinta. Vaikka Aerodisk-järjestelmien metroklusteri ei vaadi lisälisensointia (sama lisenssi on käytössä kuin replikassa), ratkaisun hinta on silti jopa korkeampi kuin synkronisen replikoinnin käyttö. Sinun on otettava käyttöön kaikki synkronisen replikan vaatimukset sekä lisäkytkentään ja lisäpaikkaan liittyvät metroklusterin vaatimukset (katso metroklusterin suunnittelu);
- Päätöksen monimutkaisuus. Metroklusteri on paljon monimutkaisempi kuin tavallinen replika, ja sen suunnittelu, määrittäminen ja dokumentointi vaatii paljon enemmän huomiota ja vaivaa.
Lopulta. Metrocluster on varmasti erittäin teknologinen ja hyvä ratkaisu, kun todella tarvitset RTO:ta sekunneissa tai minuuteissa. Mutta jos sellaista tehtävää ei ole, ja RTO tunneissa sopii liiketoiminnalle, ei ole mitään järkeä ampua varpusia tykistä. Tavanomainen työläis-talonpoika replikointi riittää, sillä metroklusteri aiheuttaa lisäkustannuksia ja monimutkaista IT-infrastruktuuria.
Metroklusterin suunnittelu
Tämän osion ei ole tarkoitus olla kattava opetusohjelma metroklusterin suunnittelusta, vaan se näyttää vain pääohjeet, jotka tulisi laatia, jos päätät rakentaa tällaisen järjestelmän. Siksi metroklusterin varsinaisessa toteutuksessa tulee ottaa varastojärjestelmän valmistaja (eli me) ja muut asiaan liittyvät järjestelmät mukaan konsultointiin.
Tapahtumapaikat
Kuten edellä mainittiin, metroklusteri vaatii vähintään kolme paikkaa. Kaksi palvelinkeskusta, joissa säilytysjärjestelmät ja niihin liittyvät järjestelmät toimivat, sekä kolmas toimipaikka, jossa välimies työskentelee.
Suositeltu palvelinkeskusten välinen etäisyys on enintään 40 kilometriä. Suurempi etäisyys aiheuttaa todennäköisesti ylimääräisiä viiveitä, jotka ovat erittäin epätoivottavia metroklusterin tapauksessa. Muista, että viiveen tulisi olla enintään 5 millisekuntia, vaikka onkin toivottavaa pysyä 2:n sisällä.
Myös viivästykset on suositeltavaa tarkistaa suunnitteluprosessin aikana. Kaikki enemmän tai vähemmän aikuiset palveluntarjoajat, jotka tarjoavat kuitua datakeskusten välillä, voivat järjestää laaduntarkistuksen melko nopeasti.
Mitä tulee välimiehen viiveisiin (eli kolmannen sivuston ja kahden ensimmäisen välillä), suositeltu viivekynnys on jopa 200 millisekuntia, eli tavallinen yrityksen VPN-yhteys Internetin kautta riittää.
Vaihto ja verkko
Toisin kuin replikointimalli, jossa riittää yhdistämään tallennusjärjestelmät eri paikoista, metroklusterimalli edellyttää isäntien yhdistämistä molempiin tallennusjärjestelmiin eri paikoissa. Alla on lueteltu molemmat järjestelmät, jotta selvennetään, mikä ero on.
Kuten kaaviosta näkyy, sivuston 1 isännät tarkastelevat sekä tallennusjärjestelmää 1 että tallennusjärjestelmää 2. Päinvastoin, sivuston 2 isännät tarkastelevat sekä tallennusjärjestelmää 2 että tallennusjärjestelmää 1. Eli jokainen isäntä näkee molemmat tallennusjärjestelmät. Tämä on metroklusterin toiminnan edellytys.
Tietenkään ei tarvitse vetää jokaista isäntää optisella johdolla toiseen datakeskukseen, portteja ja johtoja ei tule tarpeeksi. Kaikki nämä yhteydet on tehtävä Ethernet 10G+- tai FibreChannel 8G+ -kytkimien kautta (FC vain isäntien ja IO:n tallennustilan yhdistämiseen, replikointikanava on tällä hetkellä käytettävissä vain IP:n kautta (Ethernet 10G+).
Nyt muutama sana verkkotopologiasta. Tärkeä asia on aliverkkojen oikea konfigurointi. Sinun on välittömästi määritettävä useita aliverkkoja seuraaville liikennetyypeille:
- Replikoinnin aliverkko, jonka kautta tiedot synkronoidaan tallennusjärjestelmien välillä. Niitä voi olla useita, tässä tapauksessa sillä ei ole väliä, kaikki riippuu nykyisestä (jo toteutetusta) verkkotopologiasta. Jos niitä on kaksi, niiden välinen reititys on luonnollisesti määritettävä;
- Tallennusaliverkot, joiden kautta isännät pääsevät tallennusresursseihin (jos se on iSCSI). Jokaisessa datakeskuksessa pitäisi olla yksi tällainen aliverkko;
- Ohjaa aliverkkoja, eli kolme reititettävää aliverkkoa kolmessa paikassa, joista tallennustilaa hallitaan, ja siellä sijaitsee myös välimies.
Emme ota tässä huomioon aliverkkoja isäntäresurssien käyttämiseen, koska ne ovat erittäin riippuvaisia tehtävistä.
Eri liikenteen jakaminen eri aliverkkoihin on äärimmäisen tärkeää (erityisen tärkeää on erottaa replika I/O:sta), koska jos sekoitat kaiken liikenteen yhteen "paksuun" aliverkkoon, tätä liikennettä on mahdotonta hallita. kahden datakeskuksen olosuhteissa tämä voi silti aiheuttaa erilaisia verkkotörmäysvaihtoehtoja. Emme syvenny tähän aiheeseen tämän artikkelin puitteissa, koska voit lukea datakeskusten välisen verkon suunnittelusta verkkolaitevalmistajien resursseista, missä tämä on kuvattu hyvin yksityiskohtaisesti.
Arbiter-kokoonpano
Välimiehen on annettava pääsy kaikkiin tallennusjärjestelmän ohjausliitäntöihin ICMP- ja SSH-protokollien kautta. Kannattaa myös miettiä välimiehen vikasietoisuutta. Tässä on vivahde.
Arbiter-vikasiirto on erittäin toivottavaa, mutta ei pakollista. Ja mitä tapahtuu, jos välimies kaatuu väärään aikaan?
- Metroklusterin toiminta normaalitilassa ei muutu, koska arbtir ei vaikuta metroklusterin toimintaan normaalitilassa ollenkaan (sen tehtävänä on siirtää kuormitusta datakeskusten välillä ajoissa)
- Samaan aikaan, jos välimies syystä tai toisesta kaatuu ja "nukkuu" onnettomuuden datakeskuksessa, vaihtoa ei tapahdu, koska kukaan ei anna tarvittavia kytkentäkomentoja ja järjestää päätösvaltaisuuden. Tässä tapauksessa metroklusteri muuttuu tavalliseksi replikointimalliksi, joka on vaihdettava manuaalisesti katastrofin aikana, mikä vaikuttaa RTO:hon.
Mitä tästä seuraa? Jos sinun on todella tarjottava pienin RTO, sinun on varmistettava välimiehen vikasietoisuus. Tähän on kaksi vaihtoehtoa:
- Suorita virtuaalikoneen välimiehen kanssa vikasietoisessa hypervisorissa, koska kaikki aikuisten hypervisorit tukevat vikasietoisuutta.
- Jos kolmannella sivustolla (ehdollisessa toimistossa) on liian laiska asentaa normaalia klusteria eikä olemassa ole hypervisoriklusteria, niin olemme toimittaneet välimiehen laitteistoversion, joka on tehty 2U:n laatikkoon, jossa kaksi tavalliset x-86-palvelimet toimivat ja jotka selviävät paikallisesta viasta.
Suosittelemme, että varmistat välimiehen vikasietoisuuden, vaikka metroklusteri ei sitä normaalitilassa tarvitse. Mutta kuten sekä teoria että käytäntö osoittavat, jos rakennat todella luotettavan katastrofinkestävän infrastruktuurin, on parempi pelata varman päälle. On parempi suojata itseäsi ja yritystäsi "ilkeyden laista", toisin sanoen sekä välimiehen että yhden varastointijärjestelmän sijaintipaikan epäonnistumiselta.
Ratkaisuarkkitehtuuri
Ottaen huomioon yllä olevat vaatimukset, saamme seuraavan yleisen ratkaisuarkkitehtuurin.
LUN-tunnukset tulee jakaa tasaisesti molempiin paikkoihin, jotta vältytään vakavalta ruuhkalta. Samanaikaisesti, kun mitoitetaan molemmissa palvelinkeskuksissa, on välttämätöntä tarjota paitsi kaksinkertainen volyymi (mikä on tarpeen tietojen tallentamiseksi samanaikaisesti kahdelle tallennusjärjestelmälle), vaan myös kaksinkertainen suorituskyky IOPS:ssä ja MB / s:ssa, jotta estetään sovellusten heikkeneminen, jos jokin datakeskuksista epäonnistuu - ov.
Erikseen huomautamme, että oikean kokoisen lähestymistavan avulla (eli edellyttäen, että olemme varmistaneet oikeat IOPS:n ja MB/s:n ylärajat sekä tarvittavat CPU- ja RAM-resurssit), jos jokin tallennusjärjestelmistä metroklusteri epäonnistuu, ei ole vakavaa suorituskyvyn heikkenemistä olosuhteissa tilapäistä työtä yhdessä varastojärjestelmässä.
Tämä selittyy sillä, että kahden samanaikaisen sivuston olosuhteissa synkronisen replikoinnin suorittaminen "syö" puolet kirjoitussuorituskyvystä, koska jokainen tapahtuma on kirjoitettava kahteen tallennusjärjestelmään (samanlainen kuin RAID-1 / 10). Joten jos jokin tallennusjärjestelmistä epäonnistuu, replikoinnin vaikutus väliaikaisesti (kunnes epäonnistunut tallennusjärjestelmä nousee) katoaa ja kirjoitussuorituskyky kasvaa kaksinkertaiseksi. Kun viallisen tallennusjärjestelmän LUN:t käynnistettiin uudelleen toimivassa tallennusjärjestelmässä, tämä kaksinkertainen kasvu katoaa johtuen siitä, että toisen tallennusjärjestelmän LUN:ista tulee kuormitusta, ja palaamme samalle suoritustasolle, joka meillä oli ennen "pudota", mutta vain samalla alustalla.
Pätevän mitoituksen avulla on mahdollista tarjota olosuhteet, joissa käyttäjät eivät tunne koko säilytysjärjestelmän vikaa ollenkaan. Mutta jälleen kerran, tämä vaatii erittäin huolellista mitoitusta, johon voit muuten ottaa yhteyttä ilmaiseksi :-).
Metroklusterin perustaminen
Metroklusterin määrittäminen on hyvin samanlaista kuin tavallisen replikoinnin määrittäminen, jota kuvailimme kohdassa . Keskitytään siis eroihin. Laitoimme laboratorioon työpenkin yllä olevan arkkitehtuurin pohjalta, vain minimiversiossa: kaksi 10G Ethernetin kautta toisiinsa kytkettyä tallennusjärjestelmää, kaksi 10G-kytkintä ja yksi isäntä, joka katsoo kytkimien läpi molempiin 10G-porttisilla tallennusjärjestelmillä. Välimies toimii virtuaalikoneessa.
Kun määrität virtuaalista IP-osoitetta (VIP) replikalle, sinun tulee valita VIP-tyyppi - metroklusteria varten.
Loi kaksi replikointilinkkiä kahdelle LUN:lle ja jakoi ne kahdelle tallennusjärjestelmälle: LUN TEST Ensisijainen tallennustilassa1 (METRO-yhteys), LUN TEST2 Ensisijainen tallennustilalle2 (METRO2-yhteys).
Heille määritimme kaksi identtistä kohdetta (tapauksessamme iSCSI, mutta myös FC on tuettu, konfigurointilogiikka on sama).
tallennustila1:
tallennustila2:
Replikointilinkkejä varten kartoitukset tehtiin jokaisessa tallennusjärjestelmässä.
tallennustila1:
tallennustila2:
Asetimme monipolun ja esitimme sen isännälle.
Välimiehen asettaminen
Sinun ei tarvitse tehdä mitään erityistä itse sovittelijan kanssa, sinun on vain kytkettävä se päälle kolmannella sivustolla, asetettava sen IP ja määritettävä pääsy siihen ICMP:n ja SSH:n kautta. Itse konfigurointi suoritetaan itse tallennusjärjestelmistä. Samalla riittää, että määrität välimiehen kerran missä tahansa metroklusterin tallennusohjaimessa, nämä asetukset jaetaan kaikille ohjaimille automaattisesti.
Kohdassa Remote Replication>> Metrocluster (millä tahansa ohjaimella)>> Configure-painike.
Annamme välimiehen IP-osoitteen sekä kahden etätallennusohjaimen ohjausliitännät.
Tämän jälkeen sinun on otettava kaikki palvelut käyttöön (painike "Käynnistä kaikki uudelleen"). Jos määrität uudelleen myöhemmin, palvelut on käynnistettävä uudelleen, jotta asetukset tulevat voimaan.
Tarkistamme, että kaikki palvelut toimivat.
Tämä päättää metroklusterin asennuksen.
Kaatumistesti
Törmäystestistä tulee meidän tapauksessamme melko yksinkertainen ja nopea, koska replikointitoiminnallisuus (vaihto, johdonmukaisuus jne.) huomioitiin . Siksi metroklusterin luotettavuuden testaamiseksi meille riittää, että tarkistamme onnettomuuksien havaitsemisen, kytkennän automatisoinnin ja kirjoitushäviöiden (I/O-pysäytysten) puuttumisen.
Tätä varten emuloimme yhden tallennusjärjestelmän täydellistä vikaa sammuttamalla sen molemmat ohjaimet fyysisesti sen jälkeen, kun olemme alkaneet kopioida suurta tiedostoa LUN:iin, joka pitäisi aktivoida toisessa tallennusjärjestelmässä.
Poista yksi tallennusjärjestelmä käytöstä. Toisessa tallennusjärjestelmässä näemme lokeissa hälytyksiä ja viestejä, että yhteys naapurijärjestelmään on katkennut. Jos SMTP- tai SNMP-valvontailmoitukset on määritetty, asianmukaiset ilmoitukset lähetetään järjestelmänvalvojalle.
Täsmälleen 10 sekuntia myöhemmin (näkyy molemmissa kuvakaappauksissa) METRO-replikointilinkistä (se, joka oli ensisijainen kaatuneessa tallennusjärjestelmässä) tuli automaattisesti ensisijainen toimivassa tallennusjärjestelmässä. Olemassa olevaa kartoitusta käyttämällä LUN TEST pysyi isännän käytettävissä, tallennus hiipui hieman (luvatun 10 prosentin sisällä), mutta ei pysähtynyt.
Testi suoritettu onnistuneesti.
Yhteenvetona
Metroklusterin nykyinen toteutus AERODISK Engine N-sarjan tallennusjärjestelmissä mahdollistaa täysin ongelmien ratkaisemisen, joissa sinun on eliminoitava tai minimoitava IT-palvelujen seisokkiaika ja varmistettava niiden toiminta 24/7/365-tilassa minimaalisilla työvoimakustannuksilla.
Voit tietysti sanoa, että tämä kaikki on teoriaa, ihanteellisia laboratorioolosuhteita ja niin edelleen... MUTTA meillä on useita toteutettuja projekteja, joissa toteutimme katastrofipalautustoiminnon, ja järjestelmät toimivat täydellisesti. Yksi varsin tunnetuista asiakkaistamme, jossa on käytössä vain kaksi tallennusjärjestelmää katastrofikestävässä kokoonpanossa, on jo suostunut julkaisemaan tietoa projektista, joten seuraavassa osassa puhutaan taistelun toteutuksesta.
Kiitos, innolla hedelmällistä keskustelua.
Lähde: will.com