SharePoint Server 2013:n järjestelmäpalautus Microsoft Azuressa

Azuren avulla voit luoda järjestelmäpalautusympäristön paikalliselle SharePoint-klusterille. Tässä artikkelissa kuvataan, miten voit suunnitella ja ottaa käyttöön tämän ratkaisun.

Katso SharePoint Server 2013:n järjestelmäpalautuksen yleiskatsausvideo

Kun järjestelmä iskee paikalliseen SharePoint-ympäristöösi, tärkeintä on saada järjestelmä jälleen käyntiin nopeasti. Järjestelmäpalautus SharePointissa on nopeampaa ja helpompaa, kun varmuuskopiointiympäristö on jo käytössä Microsoft Azuressa. Tässä videossa kerrotaan SharePointin lämpimän vikasietoisuuden ympäristön pääkäsitteistä ja täydennetään tässä artikkelissa olevia kaikkia tietoja.

Käytä tätä artikkelia seuraavan ratkaisumallin kanssa: SharePointin järjestelmäpalautus Microsoft Azuressa.

PDF | Visio

Järjestelmäpalautuksen Azure Infrastructure Servicesin käyttäminen

Monilla organisaatioilla ei ole SharePointille järjestelmäpalautusympäristöä, jonka luominen ja ylläpitäminen paikallisesti voi olla kallista. Azure Infrastructure Services tarjoaa vaikuttavia vaihtoehtoja järjestelmäpalautusympäristöihin, jotka ovat joustavampia ja edullisempia kuin paikalliset vaihtoehdot.

Azure Infrastructure Servicesin käytön etuja ovat seuraavat:

• Vähemmän kalliita resursseja Ylläpidä ja maksa vähemmän resursseja kuin paikallisissa järjestelmäpalautusympäristöissä. Resurssien määrä riippuu valitsemastasi järjestelmäpalautusympäristöstä: kylmästä valmiustilasta, lämpimästä valmiustilasta tai kuumasta valmiustilasta.

• Entistä parempi resurssien joustavuus Jos järjestelmä on viallinen, skaalaa SharePoint-palautusklusteri helposti latausvaatimusten mukaiseksi. Skaalaa sisään, kun et enää tarvitse resursseja.

• Pienempi palvelinkeskuksen sitoutuminen Käytä Azure Infrastructure Servicesiä sen sijaan, että sijoittaisit toissijaiseen palvelinkeskukseen eri alueella.

Organisaatioilla on vähemmän monimutkaisia vaihtoehtoja vain katastrofipalautuksen aloittamiseen ja kehittyneisiin vaihtoehtoihin organisaatioille, joilla on erittäin resilienssivaatimukset. Kylmän, lämpimän ja kuuman valmiustilan ympäristöjen määritelmät ovat hieman erilaiset, kun ympäristöä isännöidään pilviympäristössä. Seuraavassa taulukossa kuvataan nämä ympäristöt SharePoint-palautusklusterin rakentamiseen Azuressa.

Taulukko: Palautusympäristöt

Palautusympäristön tyyppi	Kuvaus
Kuuma	Täysin kokoinen klusteri valmistellaan, päivitetään ja suoritetaan valmiustilassa.
Lämmin	Klusteri on luotu ja näennäiskoneet ovat käynnissä ja päivitettyinä. Palautus sisältää sisältötietokantojen liittämisen, palvelusovellusten valmistelun ja sisällön indeksoinnin. Klusteri voi olla pienempi versio tuotantoklusterista ja skaalata sen jälkeen koko käyttäjäkannan mukaiseksi.
Kylmä	Klusteri on täysin muodostettu, mutta näennäiskoneet on pysäytetty. Ympäristön ylläpitoon kuuluu näennäiskoneiden käynnistäminen ajoittain, ympäristön korjaaminen, päivittäminen ja tarkistaminen. Käynnistä koko ympäristö katastrofitilanteessa.

On tärkeää arvioida organisaatiosi palautusajan tavoitteita ja palautuspisteen tavoitteita. Nämä vaatimukset määrittävät, mikä ympäristö sopii parhaiten organisaatiollesi.

Tämän artikkelin ohjeissa kuvataan lämpimän valmiustilan käyttöönottoa. Voit myös mukauttaa sen kylmään valmiustilaan, vaikka sinun on suoritettava lisäohjeita tällaisen ympäristön tukemiseksi. Tässä artikkelissa ei kuvata kuuman valmiustilan käyttöönottoa.

Lisätietoja järjestelmäpalautusratkaisuista on ohjeaiheessa Suuren käytettävyyden ja järjestelmäpalautuksen käsitteet SharePoint 2013:ssa ja SharePoint 2013:n järjestelmäpalautusstrategian valitseminen.

Ratkaisun kuvaus

Järjestelmäpalautuksen lämmin valmiustila edellyttää seuraavaa ympäristöä:

• Paikallinen SharePoint-tuotantoklusteri

• SharePoint-klusterin palautus Azuressa

• Sivustosta sivustoon -VPN-yhteys kahden ympäristön välillä

Seuraava kuva havainnollistaa näitä kolmea elementtiä.

Kuva: Azuren lämpimän valmiustilaratkaisun elementit

SQL Server lokin toimittamista DFSR:n (Distributed File System Replication) avulla käytetään kopioimaan tietokantojen varmuuskopiot ja tapahtumalokit Azuren palautusklusteriin:

• DFSR siirtää lokit tuotantoympäristöstä palautusympäristöön. WAN-skenaariossa DFSR on tehokkaampi kuin lokien toimittamista suoraan Azuren toissijaiseen palvelimeen.

• Lokit näytetään uudelleen SQL Server Azuren palautusympäristössä.

• Et liitä lokipohjaisia SharePoint-sisältötietokantoja palautusympäristöön, ennen kuin palautusharjoitus on suoritettu.

Palauta klusteri seuraavasti:

1. Pysäytä lokin toimitus.

2. Lopeta ensisijaiseen klusteriin liikenteen hyväksyminen.

3. Toista lopulliset tapahtumalokit uudelleen.

4. Liitä sisältötietokannat klusteriin.

5. Palauta palvelusovellukset replikoiduista palvelutietokannoista.

6. Päivitä Toimialueen nimijärjestelmän (DNS) tietueet osoittamaan palautusklusteriin.

7. Aloita täysi indeksointi.

Suosittelemme, että harjoittelet näitä vaiheita säännöllisesti ja dokumentoit ne varmistaaksesi, että reaaliaikainen palautus toimii sujuvasti. Sisältötietokantojen liittäminen ja palvelusovellusten palauttaminen voi kestää jonkin aikaa, ja siihen liittyy yleensä manuaalisia määrityksiä.

Kun palautus on suoritettu, tämä ratkaisu sisältää seuraavassa taulukossa luetellut kohteet.

Taulukko: Ratkaisun palautuksen tavoitteet

Nimikkeen	Kuvaus
Sivustot ja sisältö	Sivustot ja sisältö ovat käytettävissä palautusympäristössä.
Uusi haun esiintymä	Tässä lämpimässä valmiustilassa hakua ei palauteta hakutietokannoista. Palautusklusterin hakuosat määritetään mahdollisimman samankaltaisesti kuin tuotantoklusteri. Kun sivustot ja sisältö on palautettu, hakuindeksin uudelleenmuodostaminen aloitetaan täydellisellä indeksoinnilla. Sinun ei tarvitse odottaa, että indeksointi on valmis, jotta sivustot ja sisältö ovat käytettävissä.
Palvelut	Palvelut, jotka tallentavat tietoja tietokantoihin, palautetaan lokiin toimitetuista tietokannoista. Palvelut, jotka eivät tallenna tietoja tietokantoihin, käynnistetään yksinkertaisesti. Kaikkia tietokantoja sisältäviä palveluita ei tarvitse palauttaa. Seuraavia palveluita ei tarvitse palauttaa tietokannoista, ja ne voidaan käynnistää vikasietoisuuden jälkeen: Käyttö- ja kuntotietojen kerääminen Tilapalvelu Word automation Mikä tahansa muu palvelu, joka ei käytä tietokantaa

Voit käsitellä monimutkaisempia palautustavoitteita yhdessä Microsoft Consulting Servicesin (MCS) tai kumppanin kanssa. Niistä on yhteenveto seuraavassa taulukossa.

Taulukko: Muut kohteet, joita MCS tai kumppani voi käsitellä

Nimikkeen	Kuvaus
Synkronoidaan mukautettuja klusteriratkaisuja	Ihannetapauksessa palautusklusterin määritys on sama kuin tuotantoklusteri. Voit yhdessä konsultin tai kumppanin kanssa arvioida, replikoidaanko mukautetut klusteriratkaisut ja onko prosessi käynnissä kahden ympäristön synkronoimiseksi.
Yhteydet paikallisiin tietolähteisiin	Yhteyksien replikoiminen taustatietojärjestelmiin, kuten varatoimialueen ohjauskoneen (BDC) yhteyksiin ja hakusisältölähteisiin, ei ehkä ole käytännöllistä.
Haun palautusskenaariot	Koska yrityshaun käyttöönotot ovat yleensä melko yksilöllisiä ja monimutkaisia, haun palauttaminen tietokannoista edellyttää suurempaa investointia. Voit yhdessä konsultin tai kumppanin kanssa tunnistaa ja toteuttaa haun palautusskenaarioita, joita organisaatiosi saattaa tarvita.

Tässä artikkelissa oletuksena on, että paikallinen klusteri on jo suunniteltu ja otettu käyttöön.

Yksityiskohtainen arkkitehtuuri

Ihannetapauksessa Azuren palautusklusterimääritys on identtinen paikallisen tuotantoklusterin kanssa, mukaan lukien seuraavat:

• Sama palvelinroolien esitystapa

• Sama mukautusten määritys

• Hakuosien sama määritys

Azuren ympäristö voi olla pienempi versio tuotantoklusterista. Jos aiot skaalata palautusklusterin vikasietoisuuden jälkeen, on tärkeää, että kukin palvelinrooli on aluksi edustettuna.

Jotkin kokoonpanot eivät ehkä ole käytännöllisiä replikoita vikasietoympäristössä. Muista testata vikasietoisuustoimintosarjoja ja ympäristöä varmistaaksesi, että vikasietoklusteri tarjoaa odotetun palvelutason.

Tämä ratkaisu ei määrää tiettyä topologiaa SharePoint-klusterille. Tämän ratkaisun painopisteenä on Käyttää Azurea vikasietoklusterissa ja ottaa lokitoimitus ja DFSR käyttöön kahden ympäristön välillä.

Lämpimät valmiustilaympäristöt

Lämpimässä valmiustilassa kaikki Azure-ympäristön näennäiskoneet ovat käynnissä. Ympäristö on valmis vikasietoharjoitukseen tai -tapahtumaan.

Seuraavassa kuvassa esitetään järjestelmäpalautusratkaisu paikallisesta SharePoint-klusterista Azure-pohjaiseen SharePoint-klusteriin, joka on määritetty lämpimäksi valmiustilaympäristöksi.

Kuva: Tuotantoklusterin ja lämpimän valmiustilasta palautuvan klusterin topologia ja keskeiset osat

Tässä kaaviossa:

• Kaksi ympäristöä on kuvattu rinnakkain: paikallinen SharePoint-klusteri ja Azuren lämmin valmiustilaklusteri.

• Jokainen ympäristö sisältää jaetun tiedostoresurssin.

• Jokainen klusteri sisältää neljä tasoa. Korkean käytettävyyden saavuttamiseksi kukin taso sisältää kaksi palvelinta tai näennäiskonetta, jotka on määritetty samalla tavalla tiettyä roolia varten, kuten edustapalvelut, hajautettu välimuisti, taustapalvelut ja tietokannat. Tässä kuvassa ei ole tärkeää korostaa tiettyjä osia. Kaksi klusteria on määritetty samalla tavalla.

• Neljäs taso on tietokantataso. Lokin toimittamista käytetään lokien kopioimiseen paikallisen ympäristön toissijaisesta tietokantapalvelimesta samassa ympäristössä olevaan tiedostoresurssiin.

• DFSR kopioi tiedostot paikallisessa ympäristössä olevasta jaetusta tiedostoresurssista Azure-ympäristössä jaettuun tiedostoresurssiin.

• Lokin toimitus toistaa jaetun tiedostoresurssin lokit Azure-ympäristössä ensisijaiseksi replikaksi SQL Server AlwaysOn-käytettävyysryhmässä palautusympäristössä.

Kylmät valmiustilat

Kylmässä valmiustilassa useimmat SharePoint-klusterin näennäiskoneet voidaan sulkea. (Suosittelemme, että käynnistät näennäiskoneet satunnaisesti, esimerkiksi kahden viikon välein tai kerran kuukaudessa, jotta jokainen näennäiskone voi synkronoida toimialueen kanssa.) Seuraavien Azure-palautusympäristön näennäiskoneiden on oltava käynnissä, jotta lokien toimitus ja DFSR toimivat jatkuvasti:

• Jaettu tiedostoresurssi

• Ensisijainen tietokantapalvelin

• Vähintään yksi näennäiskone, jossa on käytössä Windows Server Active Directory -toimialueen palvelut ja DNS

Seuraavassa kuvassa näkyy Azuren vikasietoympäristö, jossa tiedostoresurssin näennäiskone ja SharePoint-tietokannan ensisijainen näennäiskone ovat käynnissä. Kaikki muut SharePoint-näennäiskoneet on pysäytetty. Näennäiskonetta, jossa on käytössä Windows Server Active Directory ja DNS, ei näytetä.

Kuva: Kylmä valmiustila, jossa näennäiskoneita käytetään

Vikasietoisuuden jälkeen kylmässä valmiustilassa kaikki näennäiskoneet käynnistetään ja tietokantapalvelimien suuren käytettävyyden saavuttamismenetelmä on määritettävä, esimerkiksi SQL Server AlwaysOn-käytettävyysryhmät.

Jos useita tallennusryhmiä otetaan käyttöön (tietokannat on jaettu useaan SQL Server suuren käytettävyyden määritykseen), jokaisen tallennusryhmän ensisijaisen tietokannan on oltava käynnissä, jotta sen tallennusryhmään liittyvät lokit voidaan hyväksyä.

Osaaminen ja käyttökokemus

Tässä järjestelmäpalautusratkaisussa käytetään useita tekniikoita. Jotta voidaan varmistaa, että nämä tekniikat toimivat odotetulla tavalla, kukin paikallisen ja Azure-ympäristön osa on asennettava ja määritettävä oikein. Suosittelemme, että tämän ratkaisun luoneella henkilöllä tai ryhmällä on vahva työosaaminen ja käytännön taidot seuraavissa artikkeleissa kuvattujen tekniikoiden avulla:

• DFS (Distributed File System) -replikointipalvelut

• Windows Serverin vikasietoisuusklusterointi (WSFC), jossa on SQL Server

• AlwaysOn-käytettävyysryhmät (SQL Server)

• SQL Server tietokantojen varmuuskopioiminen ja palauttaminen

• SharePoint Server 2013:n asennus ja palvelinklusterin käyttöönotto

• Microsoft Azure

Lopuksi suosittelemme komentosarjataitoja, joiden avulla voit automatisoida näihin tekniikoihin liittyviä tehtäviä. Käytettävissä olevien käyttöliittymäen avulla voit suorittaa kaikki tässä ratkaisussa kuvatut tehtävät. Manuaalinen lähestymistapa voi kuitenkin olla aikaa vievä ja virhe altis, ja se tuottaa ristiriitaisia tuloksia.

Windows PowerShell lisäksi SQL Server, SharePoint Serverille ja Azurelle on myös Windows PowerShell kirjastoja. Älä unohda T-SQL:ää, joka voi myös lyhentää järjestelmäpalautusympäristön määrittämiseen ja ylläpitämiseen kuluvaa aikaa.

Katastrofipalautuksen etenemissuunnitelma

Tässä toteutussuunnitelmassa oletetaan, että tuotannossa on jo käyttöön otettu SharePoint Server 2013 -klusteri.

Taulukko: Järjestelmäpalautuksen etenemissuunnitelma

Vaihe	Kuvaus
Vaihe 1	Suunnittele järjestelmäpalautusympäristö.
Vaihe 2	Luo Azure-näennäisverkko ja VPN-yhteys.
Vaihe 3	Ota Windows Active Directory ja Toimialueen nimipalvelut käyttöön Azure-näennäisverkossa.
Vaihe 4	Ota SharePoint-palautusklusteri käyttöön Azuressa.
Vaihe 5	Määritä DFSR klusterien välille.
Vaihe 6	Määritä lokin toimitus palautusklusteriin.
Vaihe 7	Vikasietoisuus- ja palautusratkaisujen vahvistaminen. Tämä sisältää seuraavat menettelyt ja tekniikat: Pysäytä lokin toimitus. Palauta varmuuskopiot. Indeksoi sisältö. Palauta palvelut. DNS-tietueiden hallinta.

Vaihe 1: Järjestelmäpalautusympäristön suunnitteleminen

Microsoft Azure Architectures for SharePoint 2013 :n ohjeiden avulla voit suunnitella järjestelmäpalautusympäristön, kuten SharePoint-palautusklusterin. Voit käynnistää suunnitteluprosessin Käyttämällä SharePointin järjestelmäpalautusratkaisun grafiikkaa Azure Visio -tiedostossa . Suosittelemme, että suunnittelet koko ympäristön ennen minkään työn aloittamista Azure-ympäristössä.

Microsoft Azure Architectures for SharePoint 2013:ssa annettujen ohjeiden lisäksi, jotka koskevat näennäisverkon, VPN-yhteyden, Active Directoryn ja SharePoint-klusterin suunnittelua, muista lisätä jaettu tiedostoresurssirooli Azure-ympäristöön.

Jotta lokien toimittamista järjestelmäpalautusratkaisussa voidaan tukea, jaetun tiedostoresurssin näennäiskone lisätään aliverkkoon, jossa tietokantaroolit sijaitsevat. Jaettu tiedostoresurssi toimii myös solmuenemmistöisen solmun kolmantena solmuna SQL Server AlwaysOn-käytettävyysryhmälle. Tämä on suositeltu määritys tavalliselle SharePoint-klusterille, joka käyttää SQL Server AlwaysOn-käytettävyysryhmiä.

Huomautus

On tärkeää tarkistaa edellytykset sille, että tietokanta osallistuu SQL Server AlwaysOn-käytettävyysryhmään. Lisätietoja on ohjeaiheessa AlwaysOn-käytettävyysryhmien edellytykset, rajoitukset ja suositukset.

Kuva: Järjestelmäpalautusratkaisussa käytettävän tiedostopalvelimen sijainti

Tässä kaaviossa tiedostoresurssin näennäiskone lisätään samaan Azuren aliverkkoon, joka sisältää tietokantapalvelinroolit. Älä lisää jaetun tiedostoresurssin näennäiskonetta käytettävyysjoukkoon, jossa on muita palvelinrooleja, kuten SQL Server rooleja.

Jos olet huolissasi lokien suuresta käytettävyydestä, harkitse eri lähestymistapaa käyttämällä SQL Server varmuuskopiointia ja palautusta Azure Blob -säilöpalvelun avulla. Tämä on Azuren uusi ominaisuus, joka tallentaa lokit suoraan blob-säilön URL-osoitteeseen. Tämä ratkaisu ei sisällä ohjeita tämän ominaisuuden käytöstä.

Kun suunnittelet palautusklusteria, muista, että onnistunut järjestelmäpalautusympäristö vastaa tarkasti tuotantoklusteria, jonka haluat palauttaa. Palautusklusterin koko ei ole tärkein asia palautusklusterin suunnittelussa, käyttöönotossa ja testauksessa. Klusterin skaalaus vaihtelee organisaation mukaan liiketoimintavaatimusten mukaan. Skaalatun klusterin käyttö voi olla mahdollista lyhyen käyttökatkoksen vuoksi tai siihen asti, kunnes palvelinklusterin skaalaus edellyttää suorituskykyä ja kapasiteettia.

Määritä palautusklusteri mahdollisimman samanlaiseksi kuin mahdollista tuotantoklusterin kanssa niin, että se täyttää palvelutasosopimuksen vaatimukset ja tarjoaa toiminnot, joita tarvitset liiketoimintasi tukemiseksi. Kun suunnittelet järjestelmäpalautusympäristöä, tutustu myös tuotantoympäristösi muutostenhallintaprosessiin. Suosittelemme, että laajennat muutostenhallintaprosessin palautusympäristöön päivittämällä palautusympäristön samalla aikavälillä kuin tuotantoympäristö. Osana muutostenhallintaprosessia suosittelemme, että ylläpidät yksityiskohtaista luetteloa klusterin määrityksistä, sovelluksista ja käyttäjistä.

Vaihe 2: Azure-näennäisverkon ja VPN-yhteyden luominen

Paikallisen verkon yhdistäminen Microsoft Azure -näennäisverkkoon näyttää, miten voit suunnitella ja ottaa käyttöön näennäisverkon Azuressa ja miten VPN-yhteys luodaan. Suorita seuraavat toimet noudattamalla aiheen ohjeita:

• Suunnittele Näennäisverkko yksityinen IP-osoitetila.

• Suunnittele Näennäisverkko reititysinfrastruktuurin muutokset.

• Suunnittele paikallisen VPN-laitteen liikenteen palomuurisäännöt.

• Luo paikallinen näennäisverkko Azuressa.

• Määritä reititys paikallisen verkon ja Näennäisverkko välillä.

Vaihe 3: Active Directoryn ja toimialueen nimipalveluiden käyttöönotto Azure-näennäisverkossa

Tässä vaiheessa sekä Windows Server Active Directory että DNS otetaan käyttöön Näennäisverkko yhdistelmäskenaariossa, joka on kuvattu artikkelissa Microsoft Azure Architectures for SharePoint 2013 ja seuraavassa kuvassa esitetyllä tavalla.

Kuva: Yhdistelmä-Active Directory -toimialueen määritys

Kuvassa kaksi näennäiskonetta otetaan käyttöön samassa aliverkossa. Näillä näennäiskoneilla on kaksi roolia: Active Directory ja DNS.

Ennen kuin otat Active Directoryn käyttöön Azuressa, lue ohjeet Windows Server Active Directoryn käyttöönottoon Azure Näennäiskoneet. Näiden ohjeiden avulla voit määrittää, tarvitsetko ratkaisullesi eri arkkitehtuuria vai erilaisia määritysasetuksia.

Tarkempia ohjeita toimialueen ohjauskoneen määrittämisestä Azuressa on artikkelissa Active Directory -replikatoimialueen ohjauskoneen asentaminen Azure-näennäisverkkoihin.

Ennen tätä vaihetta et ottanut näennäiskoneita käyttöön Näennäisverkko. Näennäiskoneet Active Directoryn ja DNS:n isännöinnille eivät todennäköisesti ole suurimmat näennäiskoneet, joita tarvitset ratkaisua varten. Ennen kuin otat nämä näennäiskoneet käyttöön, luo ensin suurin näennäiskone, jota aiot käyttää Näennäisverkko. Tämä auttaa varmistamaan, että ratkaisusi perustuu Tunnisteeseen Azuressa, joka sallii suurimman tarvitsemasi koon. Sinun ei tarvitse määrittää tätä näennäiskonetta tällä hetkellä. Luo se ja aseta se syrjään. Jos et tee näin, saatat kohdata rajoituksen, kun yrität luoda suurempia näennäiskoneita myöhemmin, mikä oli ongelma tätä artikkelia kirjoitettaessa.

Vaihe 4: SharePointin palautusklusterin käyttöönotto Azuressa

Ota SharePoint-klusteri käyttöön Näennäisverkko suunnittelusuunnitelmien mukaan. Voi olla hyödyllistä tarkastella SharePoint 2013:n suunnittelua Azure Infrastructure Servicesissä ennen SharePoint-roolien käyttöönottoa Azuressa.

Ota huomioon seuraavat käytännöt, jotka opimme luomalla soveltuvuusselvitysympäristön:

• Näennäiskoneiden luominen Azure-portaali tai PowerShellin avulla.

• Azure ja Hyper-V eivät tue dynaamista muistia. Varmista, että tämä on huomioitu suorituskyky- ja kapasiteettisuunnitelmissasi.

• Käynnistä näennäiskoneet uudelleen Azure-käyttöliittymän kautta, ei itse näennäiskoneen kirjautumisen kautta. Azure-käyttöliittymän käyttäminen toimii paremmin ja on ennustettavampaa.

• Jos haluat sulkea näennäiskoneen säästääksesi kustannuksia, käytä Azure-käyttöliittymää. Jos suljet näennäiskoneen kirjautumisen, maksuja kertyy edelleen.

• Käytä nimeämiskäytäntöä näennäiskoneissa.

• Kiinnitä huomiota siihen, missä palvelinkeskuksen sijainnissa näennäiskoneet otetaan käyttöön.

• Azuren automaattista skaalausominaisuutta ei tueta SharePoint-rooleissa.

• Älä määritä palautettavan klusterin kohteita, kuten sivustokokoelmia.

Vaihe 5: DFSR:n määrittäminen klusterien välille

Voit määrittää tiedostojen replikoinnin DFSR:n avulla DNS Management -laajennuksen avulla. Kirjaudu kuitenkin ennen DFSR-asennusta paikalliseen tiedostopalvelimeen ja Azure-tiedostopalvelimeen ja ota palvelu käyttöön Windowsissa.

Suorita seuraavat vaiheet Palvelinten hallinnan koontinäytössä:

• Määritä paikallinen palvelin.

• Käynnistä ohjattu roolien ja ominaisuuksien lisääminen.

• Avaa Tiedosto- ja Tallennuspalvelut-solmu .

• Valitse DFS-nimitilat ja DFS-replikointi.

• Viimeistele ohjatun toiminnon vaiheet valitsemalla Seuraava .

Seuraavassa taulukossa on linkkejä DFSR-viiteartikkeleihin ja blogikirjoituksiin.

Taulukko: Viiteartikkelit DFSR:lle

Title	Kuvaus
Replikointi	DFS Management TechNet -aihe, jossa on linkit replikointia varten
DFS-replikointi: Selviytymisopas	Wiki, jossa on linkkejä DFS-tietoihin
DFS-replikointi: usein kysytyt kysymykset	Aihe DFS Replication TechNet
Jose Barreton blogi	Microsoftin tiedostopalvelintiimin ohjelmajohtajan blogi
Microsoftin tallennustiimi - File Cabinet -blogi	Blogi Windows Serverin tiedostopalveluista ja tallennusominaisuuksista

Vaihe 6: Lokin toimituksen määrittäminen palautusklusteriin

Lokin toimitus on tärkeä osa järjestelmäpalautuksen määrittämisessä tässä ympäristössä. Lokin toimituksen avulla voit lähettää tietokantojen tapahtumalokitiedostot automaattisesti ensisijaisesta tietokantapalvelimen esiintymästä toissijaiseen tietokantapalvelimen esiintymään. Jos haluat määrittää lokin toimituksen, katso Lokin toimituksen määrittäminen SharePoint 2013:ssa.

Tärkeää

Lokitoimitustuki SharePoint Serverissä on rajoitettu tiettyihin tietokantoihin. Lisätietoja on artikkelissa SharePoint-tietokantojen (SharePoint 2013) tuetut suuren käytettävyyden ja järjestelmäpalautuksen asetukset.

Vaihe 7: Vikasietoisuuden ja palautuksen vahvistaminen

Tämän viimeisen vaiheen tavoitteena on varmistaa, että järjestelmäpalautusratkaisu toimii suunnitellusti. Voit tehdä tämän luomalla vikasietotapahtuman, joka sulkee tuotantoklusterin ja käynnistää palautusklusterin korvaavana. Voit aloittaa vikasietotilanteet manuaalisesti tai komentosarjojen avulla.

Ensimmäinen vaihe on klusterin palveluita tai sisältöä koskevien saapuvien käyttäjäpyyntöjen lopettaminen. Voit tehdä tämän poistamalla DNS-merkinnät käytöstä tai sulkemalla edustan WWW-palvelimet. Kun klusteri on alhaalla, voit palata palautusklusteriin.

Pysäytä lokin toimitus

Lokitoimitus on pysäytettävä ennen klusterin palauttamista. Pysäytä lokin toimitus Azuren toissijaisessa palvelimessa ensin ja pysäytä se sitten ensisijaisessa palvelimessa paikallisesti. Seuraavan komentosarjan avulla voit lopettaa lokin toimituksen toissijaisessa palvelimessa ja sitten ensisijaisessa palvelimessa. Komentosarjan tietokannan nimet voivat olla erilaisia ympäristösi mukaan.

-- This script removes log shipping from the server.
-- Commands must be executed on the secondary server first and then on the primary server.

SET NOCOUNT ON
DECLARE  @PriDB nvarchar(max)
,@SecDB nvarchar(250)
,@PriSrv nvarchar(250)
,@SecSrv nvarchar(250)

Set @PriDB= ''
SET @PriDB = UPPER(@PriDB)
SET @PriDB = REPLACE(@PriDB, ' ', '')
SET @PriDB = '''' + REPLACE(@PriDB, ',', ''', ''') + ''''

Set @SecDB = @PriDB

Exec ( 'Select  ''exec master..sp_delete_log_shipping_secondary_database '' + '''''''' + prm.primary_database +  ''''''''
from msdb.dbo.log_shipping_monitor_primary prm INNER JOIN msdb.dbo.log_shipping_primary_secondaries sec  ON  prm.primary_database=sec.secondary_database
where prm.primary_database in ( ' + @PriDB + ' )')

Exec ( 'Select  ''exec master..sp_delete_log_shipping_primary_secondary '' + '''''''' + prm.Primary_Database + '''''', '''''' + sec.Secondary_Server + '''''', '''''' + sec.Secondary_database + ''''''''
from msdb.dbo.log_shipping_monitor_primary prm INNER JOIN msdb.dbo.log_shipping_primary_secondaries sec  ON  prm.primary_database=sec.secondary_database
where prm.primary_database in ( ' + @PriDB + ' )')

Exec ( 'Select  ''exec master..sp_delete_log_shipping_primary_database '' + '''''''' + prm.primary_database +  ''''''''
from msdb.dbo.log_shipping_monitor_primary prm INNER JOIN msdb.dbo.log_shipping_primary_secondaries sec  ON  prm.primary_database=sec.secondary_database
where prm.primary_database in ( ' + @PriDB + ' )')

Exec ( 'Select  ''exec master..sp_delete_log_shipping_secondary_primary '' + '''''''' + prm.primary_server + '''''', '''''' + prm.primary_database +  ''''''''
from msdb.dbo.log_shipping_monitor_primary prm INNER JOIN msdb.dbo.log_shipping_primary_secondaries sec  ON  prm.primary_database=sec.secondary_database
where prm.primary_database in ( ' + @PriDB + ' )')

Varmuuskopioiden palauttaminen

Varmuuskopiot on palautettava siinä järjestyksessä, jossa ne on luotu. Ennen kuin voit palauttaa tietyn tapahtumalokin varmuuskopion, sinun on ensin palautettava seuraavat aiemmat varmuuskopiot peruuttamatta yhdistämättömiä tapahtumia (eli käyttämällä WITH NORECOVERY):

• Täydellinen tietokannan varmuuskopiointi ja viimeinen eroavuusvarmuuskopiointi - Palauta nämä varmuuskopiot, jos niitä on, ennen tiettyä tapahtumalokin varmuuskopiointia. Ennen kuin viimeisin täysi tai eroavuusinen tietokannan varmuuskopiointi luotiin, tietokanta käytti täyttä palautusmallia tai joukkokirjattua palautusmallia.

• Kaikki tapahtumalokin varmuuskopiot – Palauta kaikki tapahtumalokin varmuuskopiot, jotka on otettu täyden tietokannan varmuuskopioinnin tai eroavuusvarmuuskopiointin jälkeen (jos palautat sellaisen) ja ennen tiettyä tapahtumalokin varmuuskopiointia. Lokivarmuuskopiointia on käytettävä siinä järjestyksessä, jossa ne luotiin, ilman aukkoja lokiketjussa.

Jos haluat palauttaa toissijaisen palvelimen sisältötietokannan sivustojen hahmontamista varten, poista kaikki tietokantayhteydet ennen palauttamista. Palauta tietokanta suorittamalla seuraava SQL-lause.

restore database WSS_Content with recovery

Tärkeää

Kun käytät T-SQL:ää eksplisiittisesti, poista moniselitteisyys määrittämällä JOKO NORECOVERY tai WITH RECOVERY jokaisessa RESTORE-lauseessa – tämä on erittäin tärkeää komentosarjoja kirjoitettaessa. Kun täysi ja eroavuusvarmuuskopiointi on palautettu, tapahtumalokit voidaan palauttaa SQL Server Management Studio. Koska lokin toimitus on jo pysäytetty, sisältötietokanta on valmiustilassa, joten sinun on muutettava tilaksi täydet käyttöoikeudet.

Napsauta SQL Server Management Studio WSS_Content tietokantaa hiiren kakkospainikkeella, valitse Tehtävien>palauttaminen ja valitse sitten Tapahtumaloki (jos et ole palauttanut koko varmuuskopiota, tämä ei ole käytettävissä). Lisätietoja on artikkelissaTapahtumalokin varmuuskopioinnin (SQL Server) palauttaminen.

Indeksoi sisältölähde

Kunkin sisältölähteen täydellinen indeksointi on aloitettava, jotta hakupalvelu voidaan palauttaa. Huomaa, että menetät joitakin paikallisen klusterin analytiikkatietoja, kuten hakusuosituksia. Ennen kuin aloitat täydet indeksoinnit, käytä Windows PowerShell cmdlet Restore-SPEnterpriseSearchServiceApplication -toimintoa ja määritä lokiin toimitettu ja replikoitu haun hallintatietokanta Search_Service__DB_<GUID>. Tämä cmdlet-komento antaa hakumäärityksen, rakenteen, hallitut ominaisuudet, säännöt ja lähteet ja luo oletusjoukon muista osista.

Voit aloittaa täydellisen indeksoinnin suorittamalla seuraavat vaiheet:

1. Siirry SharePoint 2013:n keskitetyssä hallinnassa kohtaan Sovellustenhallintapalvelusovellukset>Palvelusovellusten> hallinta ja napsauta sitten hakupalvelusovellusta, jonka haluat indeksoida.

2. Valitse Haun hallinta -sivulla Sisältölähteet, osoita haluamaasi sisältölähdettä, napsauta nuolta ja valitse sitten Aloita täysi indeksointi.

Palauta klusterin palvelut

Seuraavassa taulukossa näytetään, miten voit palauttaa palvelut, joissa on lokipohjaisia tietokantoja, palvelut, joissa on tietokantoja, mutta joita ei suositella palautettavaksi lokitoimituksen yhteydessä, sekä palvelut, joissa ei ole tietokantoja.

Tärkeää

Paikallisen SharePoint-tietokannan palauttaminen Azure-ympäristöön ei palauta Mitään SharePoint-palveluita, joita et vielä asentanut Azureen manuaalisesti.

Taulukko: Palvelusovelluksen tietokantaviittaus

Palauta nämä palvelut lokiin toimitetuista tietokannoista	Näissä palveluissa on tietokantoja, mutta suosittelemme, että käynnistät nämä palvelut palauttamatta niiden tietokantoja	Nämä palvelut eivät tallenna tietoja tietokantoihin. käynnistää nämä palvelut vikasietoisuuden jälkeen
Konekäännöspalvelu Hallittujen metatietojen palvelu Suojattu säilöpalvelu Käyttäjäprofiilin. (Vain profiilin ja sosiaalisten tunnisteiden tietokantoja tuetaan. Synkronointitietokantaa ei tueta.) Microsoft SharePoint Foundationin tilausasetuspalvelu	Käyttö- ja kuntotietojen kerääminen Tilapalvelu Word automation	Excel-palvelut PerformancePoint-palvelut PowerPoint-muunnos Visio Graphics Service Työnhallinta

Seuraavassa esimerkissä näytetään, miten voit palauttaa hallittujen metatietojen palvelun tietokannasta.

Tämä käyttää aiemmin luotua Managed_Metadata_DB tietokantaa. Tämä tietokanta on lokitiedosto, mutta toissijaisessa klusterissa ei ole aktiivista palvelusovellusta, joten se on yhdistettävä, kun palvelusovellus on käytössä.

Käytä ensin -parametria New-SPMetadataServiceApplicationja määritä valitsin DatabaseName palautetun tietokannan nimellä.

Määritä seuraavaksi uusi hallittujen metatietojen palvelusovellus toissijaiseen palvelimeen seuraavasti:

• Nimi: Hallittujen metatietojen palvelu

• Tietokantapalvelin: Lähetetyn tapahtumalokin tietokannan nimi

• Tietokannan nimi: Managed_Metadata_DB

• Sovellussarja: SharePoint-palvelusovellukset

DNS-tietueiden hallinta

DNS-tietueet on luotava manuaalisesti osoittamaan SharePoint-klusteriin.

Useimmissa tapauksissa, joissa sinulla on useita edustaverkkopalvelimia, on järkevää hyödyntää Windows Server 2012:n Network Load Balancing -ominaisuutta tai laitteiston kuormituksentasainta pyyntöjen jakamiseen klusterin verkkokäyttöisten edustapalvelimien kesken. Verkon kuormituksen tasaaminen voi myös auttaa pienentämään riskiä jakamalla pyyntöjä muille palvelimille, jos jokin verkon edustapalvelimista epäonnistuu.

Yleensä, kun määrität verkon kuormituksen tasausta, klusterille määritetään yksi IP-osoite. Sen jälkeen voit luoda DNS-isäntätietueen verkon DNS-palvelussa, joka osoittaa klusteriin. (Tässä projektissa dns-palvelin sijoitetaan Azureen vikasietoisuuden vuoksi, jos paikallinen palvelinkeskus epäonnistuu.) Voit esimerkiksi luoda DNS-tietueen Dns Managerissa Active Directoryssa, esimerkiksi nimellä https://sharepoint.contoso.com, joka osoittaa kuormituksen tasapainotetun klusterin IP-osoitteeseen.

SharePoint-klusterin ulkoista käyttöä varten voit luoda isäntätietueen ulkoiseen DNS-palvelimeen samalla URL-osoitteella, jota asiakkaat käyttävät intranetissäsi (esimerkiksi https://sharepoint.contoso.com), joka osoittaa palomuurin ulkoiseen IP-osoitteeseen. (Tässä esimerkissä paras käytäntö on määrittää jaettu DNS niin, että sisäinen DNS-palvelin on tärkeä contoso.com ja reitittää pyynnöt suoraan SharePoint-klusteriin sen sijaan, että dns-pyynnöt reititetään ulkoiseen DNS-palvelimeen.) Voit sitten yhdistää ulkoisen IP-osoitteen paikallisen klusterin sisäiseen IP-osoitteeseen, jotta asiakkaat löytävät etsimänsä resurssit.

Täältä voit kohdata muutamia erilaisia järjestelmäpalautusskenaarioita:

Esimerkkiskenaario: Paikallinen SharePoint-klusteri ei ole käytettävissä paikallisen SharePoint-klusterin laitteistovirheen vuoksi. Tässä tapauksessa, kun olet suorittanut vikasietoisuuden vaiheet Azure SharePoint -klusterissa, voit määrittää verkon kuormituksen tasauksen SharePoint-klusterin verkkoedustapalvelimissa samalla tavalla kuin paikallisessa klusterissa. Voit sitten uudelleenohjata isäntätietueen sisäisessä DNS-palvelussa osoittamaan palautusklusterin klusterin IP-osoitteeseen. Huomaa, että voi kestää jonkin aikaa, ennen kuin asiakkaiden välimuistissa olevat DNS-tietueet päivitetään, ja osoittaa palautusklusteriin.

Esimerkkiskenaario: Paikallinen palvelinkeskus menetetään kokonaan. Tämä skenaario voi ilmetä luonnonkatastrofin, kuten tulipalon tai tulvan, vuoksi. Tässä tapauksessa jos kyseessä on yritys, sinulla on todennäköisesti toissijainen palvelinkeskus, jota isännöidään toisella alueella, sekä Azure-aliverkko, jolla on omat hakemistopalvelut ja DNS. Kuten edellisessä katastrofiskenaariossa, voit ohjata sisäiset ja ulkoiset DNS-tietueet osoittamaan Azure SharePoint -klusteriin. Huomaa jälleen, että DNS-tietueiden levittäminen voi kestää jonkin aikaa.

Jos käytät isäntänimisivustokokoelmia, joita suositellaan Isäntänimi-sivustokokoelman arkkitehtuurissa ja käyttöönotossa (SharePoint 2013), sinulla saattaa olla useita sivustokokoelmia, joita isännöi sama verkkosovellus SharePoint-klusterissasi ja joissa on yksilölliset DNS-nimet (esimerkiksi https://sales.contoso.com ja https://marketing.contoso.com). Tässä tapauksessa voit luoda DNS-tietueita kullekin sivustokokoelmalle, joka osoittaa klusterin IP-osoitteeseen. Kun pyyntö on saavuttanut SharePointin www-edustapalvelimet, ne käsittelevät jokaisen pyynnön reitittämisen asianmukaiseen sivustokokoelmaan.

Microsoftin soveltuvuusselvitysympäristö

Suunnittelimme ja testasimme ratkaisun soveltuvuusselvitysympäristön. Testiympäristön suunnittelutavoitteena oli ottaa käyttöön ja palauttaa SharePoint-klusteri, joka saattaa löytyä asiakasympäristöstä. Teimme useita oletuksia, mutta tiesimme, että klusterin oli tarjottava kaikki käyttövalmiit toiminnot ilman mukautuksia. Topologia on suunniteltu korkeaan käytettävyyteen kentän ja tuoteryhmän parhaiden käytäntöjen ohjeiden avulla.

Seuraavassa taulukossa kuvataan Hyper-V-näennäiskoneet, jotka loimme ja määritimme paikalliselle testiympäristölle.

Taulukko: Näennäiskoneet paikallista testausta varten

Palvelimen nimi	Rooli	Määritykset
TASAVIRTA 1	Toimialueen ohjauskone ja Active Directory.	Kaksi suoritinta Alkaen 512 Mt - 4 Gt RAM 1 x 127 Gt kiintolevy
RRAS	Palvelimelle on määritetty reititys- ja etäkäyttöpalvelu (RRAS) -rooli.	Kaksi suoritinta 2–8 Gt RAM-muistia 1 x 127 Gt kiintolevy
FS1	Tiedostopalvelin, jossa on jaetut varmuuskopiot ja päätepiste DFSR:lle.	Neljä suoritinta 2–12 Gt RAM-muistia 1 x 127 Gt kiintolevy 1 x 1 Tt kiintolevy (SAN) 1 x 750 Gt:n kiintolevy
SP-WFE1, SP-WFE2	Edustan WWW-palvelimet.	Neljä suoritinta 16 Gt RAM-muistia
SP-APP1, SP-APP2, SP-APP3	Sovelluspalvelimet.	Neljä suoritinta 2–16 Gt RAM-muistia
SP-SQL-HA1, SP-SQL-HA2	Tietokantapalvelimet, jotka on määritetty SQL Server 2012 AlwaysOn-käytettävyysryhmillä suuren käytettävyyden tarjoamiseksi. Tässä kokoonpanossa käytetään sp-SQL-HA1- ja SP-SQL-HA2-replikoita ensisijaisina ja toissijaisina replikoina.	Neljä suoritinta 2–16 Gt RAM-muistia

Seuraavassa taulukossa kuvataan sellaisten Hyper-V-näennäiskoneiden aseman määritykset, jotka loimme ja määritimme edustaverkkoa ja sovelluspalvelimia varten paikallisessa testiympäristössä.

Taulukko: Näennäiskoneen käyttövaatimukset Front Endin verkko- ja sovelluspalvelimille paikallista testiä varten

Asemakirjain	Koko	Hakemiston nimi	Polku
C	80	Järjestelmäasema	<DriveLetter>:\Program Files\Microsoft SQL Server\
E	80	Lokiasema (40 Gt)	<DriveLetter>:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA
F	80	Sivu (36 Gt)	<DriveLetter>:\Program Files\Microsoft SQL Server\MSSQL\DATA

Seuraavassa taulukossa kuvataan aseman määritykset hyper-V-näennäiskoneille, jotka on luotu ja määritetty toimimaan paikallisina tietokantapalvelimina. Voit määrittää ja vahvistaa seuraavassa taulukossa näkyvät asetukset Tietokantamoduulin määritys -sivulla Tietohakemistot-välilehdessä .

Taulukko: Näennäiskoneen käyttövaatimukset tietokantapalvelimelle paikallista testiä varten

Asemakirjain	Koko	Hakemiston nimi	Polku
C	80	Tietojen päähakemisto	<DriveLetter>:\Program Files\Microsoft SQL Server\
E	500	Käyttäjän tietokantahakemisto	<DriveLetter>:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA
F	500	Käyttäjän tietokannan lokihakemisto	<DriveLetter>:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA
G	500	Tilapäishakemisto	<DriveLetter>:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA
H	500	Tilapäisen tietokannan lokihakemisto	<DriveLetter>:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA

Testiympäristön määrittäminen

Eri käyttöönottovaiheiden aikana testiryhmä työskenteli yleensä ensin paikallisessa arkkitehtuurissa ja sitten vastaavassa Azure-ympäristössä. Tämä kuvastaa yleisiä todellisia tapauksia, joissa käytössä on jo sisäisiä tuotantotiloja. Vielä tärkeämpää on, että tiedät nykyisen tuotantokuormituksen, kapasiteetin ja tyypillisen suorituskyvyn. Sen lisäksi, että luot järjestelmäpalautusmallin, joka voi vastata liiketoiminnan vaatimuksia, sinun tulee määrittää palautusklusterin palvelimien koko, jotta palvelutaso olisi mahdollisimman pieni. Kylmässä tai lämpimässä valmiustilassa palautusklusteri on yleensä pienempi kuin tuotantotila. Kun palautusklusteri on vakaa ja tuotannossa, klusteria voidaan skaalata ylös ja ulos kuormitusvaatimusten täyttämiseksi.

Olemme ottaneet testiympäristömme käyttöön seuraavissa kolmessa vaiheessa:

• Yhdistelmäinfrastruktuurin määrittäminen

• Palvelinten valmisteleminen

• Ota SharePoint-klusterit käyttöön

Yhdistelmäinfrastruktuurin määrittäminen

Tässä vaiheessa määritettäessä toimialueympäristöä paikalliselle klusterille ja palautusklusterille Azuressa. Active Directoryn määrittämiseen liittyvien normaalien tehtävien lisäksi testiryhmä otti käyttöön reititysratkaisun ja VPN-yhteyden kahden ympäristön välillä.

Palvelinten valmisteleminen

Klusterin palvelimien lisäksi toimialueen ohjauskoneille oli valmistettava palvelimia ja määritettävä palvelin käsittelemään RRAS-palvelimia sekä sivuston ja sivuston välistä VPN:ää. DFSR-palvelua varten valmisteltiin kaksi tiedostopalvelinta ja testareita varten valmisteltiin useita asiakastietokoneita.

Ota SharePoint-klusterit käyttöön

SharePoint-klusterit otettiin käyttöön kahdessa vaiheessa, jotta ympäristön vakauttamista ja vianmääritystä voidaan tarvittaessa yksinkertaistaa. Ensimmäisen vaiheen aikana kukin klusteri otettiin käyttöön vähimmäismäärässä palvelimia topologian kullakin tasolla vaadittujen toimintojen tukemiseksi.

Loimme tietokantapalvelimet, joihin on asennettu SQL Server ennen SharePoint 2013 -palvelimien luomista. Koska tämä oli uusi käyttöönotto, loimme käytettävyysryhmät ennen SharePointin käyttöönottoa. Loimme kolme ryhmää MCS:n parhaiden käytäntöjen ohjeiden perusteella.

Huomautus

Luo paikkamerkkitietokantoja, jotta voit luoda käytettävyysryhmiä ennen SharePoint-asennusta. Lisätietoja on kohdassa SQL Server 2012 AlwaysOn availability groups for SharePoint 2013

Klusteri luotiin ja lisäpalvelimet liitettiin seuraavassa järjestyksessä:

• Provision SP-SQL-HA1 ja SP-SQL-HA2.

• Määritä AlwaysOn ja luo kolme käytettävyysryhmää klusterille.

• Valmistele SP-APP1 isännöimään keskitettyä hallintaa.

• Valmistele SP-WFE1 ja SP-WFE2 ja isännöi hajautettua välimuistia.

SkipRegisterAsDistributedCachehost-parametria käytettiin , kun komentorivillä suoritettiinpsconfig.exe. Lisätietoja on artikkelissa Syötteiden ja hajautetun välimuistin palvelusopimus SharePoint Server 2013:ssa.

Palautusympäristössä toistettiin seuraavat vaiheet:

• Provision AZ-SQL-HA1 ja AZ-SQL-HA2.

• Määritä AlwaysOn ja luo kolme käytettävyysryhmää klusterille.

• Valmistele AZ-APP1 isännöimään keskitettyä hallintaa.

• Valmistele AZ-WFE1 ja AZ-WFE2 ja isännöi hajautettua välimuistia.

Kun olemme määrittäneet hajautetun välimuistin ja lisänneet testikäyttäjiä ja testisisältöä, aloitimme käyttöönoton toisen vaiheen. Tämä edellytti tasojen skaalausta ja palvelinklusterin palvelimien määrittämistä tukemaan klusterin arkkitehtuurissa kuvattua suuren käytettävyyden topologiaa.

Seuraavassa taulukossa kuvataan palautusklusterille määrittämämme näennäiskoneet, aliverkot ja käytettävyysjoukot.

Taulukko: Palautusklusterin infrastruktuuri

Palvelimen nimi	Rooli	Määritykset	Aliverkon	Käytettävyysjoukko
spDRAD	Toimialueen ohjauskone ja Active Directory	Kaksi suoritinta Alkaen 512 Mt - 4 Gt RAM 1 x 127 Gt kiintolevy	sp-AD-palvelimet
AZ-SP-FS	Tiedostopalvelin, jossa on jaetut varmuuskopiot ja päätepiste DFSR:lle	A5-määritys: Kaksi suoritinta 14 Gt RAM-muistia 1 x 127 Gt kiintolevy 1 x 135 Gt kiintolevy 1 x 127 Gt kiintolevy 1 x 150 Gt kiintolevy	sp-databaseservers	DATA_SET
AZ-WFE1, AZ -WFE2	Edustan WWW-palvelimet	A5-määritys: Kaksi suoritinta 14 Gt RAM-muistia 1 x 127 Gt kiintolevy	sp-webservers	WFE_SET
AZ -APP1, AZ -APP2, AZ -APP3	Sovelluspalvelimet	A5-määritys: Kaksi suoritinta 14 Gt RAM-muistia 1 x 127 Gt kiintolevy	sp-applicationservers	APP_SET
AZ -SQL-HA1, AZ -SQL-HA2	AlwaysOn-käytettävyysryhmien tietokantapalvelimet sekä ensisijaiset ja toissijaiset replikat	A5-määritys: Kaksi suoritinta 14 Gt RAM-muistia	sp-databaseservers	DATA_SET

Operations

Kun testiryhmä oli vakauttanut klusterin ympäristöt ja suorittanut toiminnallisen testauksen, he aloittivat seuraavat toiminnot, joita tarvitaan paikallisen palautusympäristön määrittämiseen:

• Määritä täysi ja eroavuus -varmuuskopiot.

• Määritä DFSR tiedostopalvelimiin, jotka siirtävät tapahtumalokeja paikallisen ympäristön ja Azure-ympäristön välillä.

• Määritä lokin toimitus ensisijaisessa tietokantapalvelimessa.

• Vakautta, vahvista ja tee lokin toimituksen vianmääritys tarpeen mukaan. Tähän sisältyi ongelmia mahdollisesti aiheuttavan toiminnan tunnistaminen ja dokumentointi, kuten verkkoviive, joka aiheuttaisi lokin toimitusvirheitä tai DFSR-tiedostojen synkronointivirheitä.

Tietokannat

Vikasietotestit koskivat seuraavia tietokantoja:

• WSS_Content

• ManagedMetadata

• Profiilitietokanta

• Synkronoi tietokanta

• Yhteisöpalvelutietokanta

• Sisältötyyppikeskus (tietokanta erilliselle sisältötyypin syndikointitoiminnolle)

Vianmääritysvihjeitä

Osiossa kerrotaan testauksen aikana kohtaamistamme ongelmista ja niiden ratkaisuista.

Termisäilön hallintatyökalun käyttäminen aiheutti virheen: Hallittu metatietosäilö tai yhteys ei ole tällä hetkellä käytettävissä.

Varmista, että verkkosovelluksen käyttämällä sovellussarjatilillä on termisäilön lukuoikeudet.

Mukautetut termijoukot eivät ole käytettävissä sivustokokoelmassa

Tarkista puuttuva palvelusovelluksen kytkentä sisältösivustokokoelman ja sisältötyyppikeskuksen välillä. Varmista lisäksi Hallitut metatiedot – <sivustokokoelman nimi> Yhteyden ominaisuudet -näytössä, että tämä asetus on käytössä: Tämä palvelusovellus on sarakekohtaisten termijoukkojen oletusarvoinen tallennussijainti.

Get-ADForest Windows PowerShell-komento luo virheen. Termiä Get-ADForest ei tunnisteta cmdlet-komennon, funktion, komentosarjatiedoston tai hallittavan ohjelman nimeksi.

Kun määrität käyttäjäprofiileja, tarvitset Active Directory -toimialuepuuryhmän nimen. Varmista ohjatussa roolien ja ominaisuuksien lisäämisen toiminnossa, että olet ottanut Active Directory -moduulin käyttöön Windows PowerShell varten (Etäpalvelimen hallintatyökalujen roolien>hallintatyökalut>AD DS- ja AD LDS -työkalut -osassa). Varmista lisäksi, että ohjelmistoriippuvuutesi ladataan suorittamalla seuraavat komennot ennen Get-ADForest-kohteen käyttöä.

Import-Module ServerManager
Import-Module ActiveDirectory

Käytettävyysryhmän luonti epäonnistuu, kun AlwaysOn_health XEvent-istunnon aloittaminen palvelimen nimessä<>

Varmista, että vikasietoklusterin molemmat solmut ovat tilassa "Ylös" eivätkä "Keskeytetty" tai "Pysäytetty".

SQL Server lokin toimitustyö epäonnistuu. Käyttö estetty virhe yritettäessä muodostaa yhteyttä jaettuun tiedostoresurssiin

Varmista, että SQL Server -agentti suoritetaan verkon tunnistetiedoilla oletusarvoisten tunnistetietojen sijaan.

SQL Server lokin toimitustyö osoittaa onnistumisesta, mutta tiedostoja ei kopioida

Näin tapahtuu, koska käytettävyysryhmän oletusarvoinen varmuuskopiointiasetus on Toissijainen. Varmista, että suoritat lokin toimitustyön toissijaisesta palvelimesta käytettävyysryhmälle ensisijaisen sijaan. muussa tapauksessa työ epäonnistuu taustalla.

Hallittujen metatietojen palvelu (tai muu SharePoint-palvelu) ei käynnisty automaattisesti asennuksen jälkeen

Palveluiden käynnistyminen voi kestää useita minuutteja SharePoint Serverin suorituskyvyn ja nykyisen kuormituksen mukaan. Valitse palvelun käynnistäminen manuaalisesti ja anna riittävästi aikaa käynnistykseen, kun päivität ajoittain Palvelin-näytön Palveluita. Näin voit valvoa palvelun tilaa. Jos palvelu pysyy pysäytettynä, ota SharePointin diagnostiikan kirjaus käyttöön, yritä käynnistää palvelu uudelleen ja tarkista lokista virheet. Lisätietoja on artikkelissa Diagnostiikan kirjaamisen määrittäminen SharePoint 2013:ssa

Kun DNS on muutettu Azuren vikasietoympäristöön, asiakasselaimissa käytetään edelleen SharePoint-sivuston vanhaa IP-osoitetta

DNS-muutoksesi ei ehkä näy kaikille asiakkaille heti. Suorita testiasiakkaassa seuraava komento järjestelmänvalvojan oikeellinen komentokehotteesta ja yritä käyttää sivustoa uudelleen.

Ipconfig /flushdns

Lisäresurssit

SharePoint-tietokantojen tuetut suuren käytettävyyden ja järjestelmäpalautuksen asetukset

Määritä SQL Server 2012 AlwaysOn availability groups for SharePoint 2013

Katso myös

Microsoft 365 -ratkaisu- ja arkkitehtuurikeskus