Data Domain: Hakemistojen ja varantojen replikoinnin parhaat käytännöt

Hakemistojen replikoinnin parhaat käytännöt

TARKOITUS

Tässä artikkelissa määritetään hakemistoreplikoinnin määrittämisen parhaat käytännöt.

KOSKEE SEURAAVIA:

• Kaikki Data Domain -järjestelmät
• Kaikki ohjelmistojulkaisut

SUOSITUKSIA

1. Jaa työtaakka mahdollisimman moneen kontekstiin.
   Ihanteellinen yhden kontekstin esipakattu suorituskyky on 200–300 Mt/s. Kokoonpanoissa, joissa monisuoratoisto on käytettävissä, ihanteellinen yhden kontekstin suorituskyky on samanlainen kuin ihanteellinen monikontekstinen suorituskyky. On kuitenkin olemassa useita muuttujia, jotka rajoittavat monisuoratoiston tehokkuutta:

   • Jos DDR-lähdemoduulilla on useita replikointikonteksteja, logiikka, jolla monisuoratoistovirrat jaetaan kontekstien kesken, rajoittaa käytettävissä olevien virtojen määrää.
   • Monisuoratoisto ei ole aktiivista tilannevedoksiin perustuvan alustuksen/palautuksen aikana. Tilannevedoksiin perustuva alustus on oletusarvoisesti käytössä, jos lähdekontekstissa on yli miljoona merkintää.
   • 5.0: sta lähtien monisuoratoisto otettiin käyttöön CIFS-tietojen replikointia varten.

   Ihanteellinen monikontekstinen esipakattu suoritusteho vaihtelee noin 200 Mt/s:n ja 500 Mt/s:n välillä tai enemmän.

2. Suunnittele kuormitus keskikokoisilla tiedostoilla.
   Tiedostokoolla voi olla merkittävä vaikutus replikointikontekstin yleiseen suorituskykyyn. Yleensä alle 10 Mt:n tiedostoja ei voida replikoida tehokkaasti.

   Kun replikointipari muodostaa yhteyden uudelleen yhteyden odottamattoman katkeamisen jälkeen, lähteen on käynnistettävä uudelleen yhteyden katkeamisen aikana replikoidun tiedoston alusta. Jos tiedosto on hyvin suuri ja yhteys katkeaa usein (esimerkiksi epäluotettavan verkon vuoksi), replikointi voi käytännössä jumittua? yritetään replikoida sama tiedosto yhä uudelleen. Tämä näkyy yleisimmin tiedostoissa, joiden koko on yli 100 Gt. Itse tiedostokoolla ei ole vaikutusta suorituskykyyn.

3. Suunnittele kuormitus hyödyntämään replikoinnin ajoitusta.
   Tiedostot asetetaan replikointijonoon, kun ne suljetaan sisäisesti. Tiedoston sulkeminen ajoitetaan seuraavasti:

   Kun muokattu tiedosto suljetaan, tiedostolle luodaan replikointilokin "close"-tietue. Replikointi asettaa tiedoston uudet tiedot jonoon lähetettäväksi. Jos jonossa ei ole muita replikointitoimintoja (eli käsittelemättömiä lokitietueita), uudet tiedot lähetetään välittömästi. Muussa tapauksessa tiedosto replikoidaan sen jälkeen, kun aiemmat lokitietueet on käsitelty.

   • 10 minuutin kuluttua viimeisestä käyttökerrasta NFS sulkee tiedoston.
   • Kaikki tiedostot suljetaan tunnin välein riippumatta siitä, kuinka äskettäin ne on kirjoitettu.
   • Jos tiedostoa käytetään tai kirjoitetaan useita, tiedostot saatetaan sulkea nopeammin kuin edellä mainitut säännöt edellyttävät. Varmuuskopio-ohjelmisto kirjoittaa tiedostoja pienempinä osina (esimerkiksi 1 Mt), mikä voi johtaa replikoinnin alkamiseen nopeammin luotavien tiedostojen määrän vuoksi.

4. Käytä erillistä verkkoa, jos mahdollista.
   Jopa 0,1 %:n pakettihävikki voi heikentää vakavasti verkon siirtonopeutta, erityisesti suuren kaistanleveyden viiveellä varustetuissa verkoissa. Verkoissa, joiden kaistanleveys <= T2, RTT (edestakainen aika) jopa sekuntiin asti tarjoaa hyvän siirtonopeuden. Verkoissa, joissa >on = T3, on merkittävää suorituskyvyn heikkenemistä alkaen RTT: stä 300-500ms.

   Yleisemmin läpimeno pakettihävikissä on suunnilleen
   Läpimeno = MSS /(RTT * sqrt(p)) missä MSS := segmentin vähimmäiskoko (tyypillisesti 1460 tavua) RTT := edestakainen aika p := pakettihävikin todennäköisyys

5. Delta-replikoinnin (pienen kaistanleveyden optimointi) arviointi
   DD OS 4.8:ssa ja uudemmissa versioissa deltareplikointi, jota kutsutaan myös pienen kaistanleveyden optimoinniksi, voi lisätä hakemistojen tai varantojen replikoinnin virtuaalista siirtonopeutta linkeissä, joiden käytettävissä oleva kaistanleveys on alle 6 megabittiä sekunnissa (Mbps). Deltareplikointi aiheuttaa merkittävästi ylimääräisiä suoritin- ja I/O-yleiskustannuksia sekä lähde- että kohdeData Domain -järjestelmissä. Jos pienen kaistanleveyden optimointi on käytössä linkeillä, joiden kaistanleveys on yli 6 Mbps, on epätodennäköistä, että virtuaalisen siirtonopeuden kasvu toteutuu. Yleisesti ottaen, jos:

   • Replikoitavat tiedot ovat alle 96-prosenttisesti identtisiä kohdejärjestelmässä jo olevien tietojen kanssa
   • Käytettävissä olevaa kaistanleveyttä on alle 6 Mbps
   • Molemmissa järjestelmissä on ylimääräistä suoritin- ja I/O-kapasiteettia

     Pienen kaistanleveyden optimointi on otettava käyttöön. Tarkkaile "replication show history" -tuloksen tulosta useiden viikkojen ajan. "Low-bw-optim" -suhteen tulisi olla keskimäärin 2,00 tai enemmän, ja verkon läpäisykyvyn (verkkotavut jaettuna aikavälillä) ei pitäisi olla paljon pienempi kuin käytettävissä oleva kaistanleveys. Jos "Low-bw-optim" -suhde ei ole keskimäärin 2,00 tai enemmän, delta-pakkaus ei todennäköisesti toimi tietojoukossa ja se on poistettava käytöstä. Jos verkon siirtonopeus on paljon pienempi kuin käytettävissä oleva kaistanleveys, toisessa tai kummassakaan Data Domain -järjestelmässä ei todennäköisesti ole riittävästi varasuoritinta tai I/O-kapasiteettia delta-replikoinnin tukemiseen, ja se on poistettava käytöstä.

6. Noudata muiden komponenttien ja kolmannen osapuolen varmuuskopiointisovellusten parhaita käytäntöjä.
   Parhaiden käytäntöjen oppaamme on suunniteltu yleistä suorituskykyä ajatellen. Poikkeamilla ehdotetuista Data Domainsin parhaista käytännöistä voi olla merkittäviä vaikutuksia suorituskykyyn useilla alueilla, vaikka se ei välttämättä ole heti ilmeistä.

VIITE

Replikoinnin viiveen vianmääritys 180482