Siirrossa huomioon otettavia seikkoja

24 minuuttia

Paikallisesti suoritettavalla liiketoimintajärjestelmällä voi olla arkkitehtuuri, joka on yhdistetty muihin samassa ympäristössä toimiviin palveluihin. On tärkeää ymmärtää siirrettävän järjestelmän ja muiden organisaatiosi tällä hetkellä käyttämien sovellusten ja palveluiden väliset suhteet.

Teknologia-alan startup-yrityksessäsi toimittajatietokannan avulla varmistetaan, että komponentteja on aina varastossa ja ne saapuvat juuri oikeaan aikaan valmistusprosessiin käytettäväksi. Varastonvalvojat käyttävät mobiililaitteita tämän tietokannan päivittämiseen lähetysten saapuessa, ja ostajat käyttävät verkkosivustoa varastotasojen seuraamiseen ja parhaan tilausajan tunnistamiseen. Esimiehet käyttävät joukkoa liiketoimintakriittisiä raportteja prosessin seurantaan ja tehokkuuden parantamiseen. Haluat varmistaa, että Azureen siirtyminen ei vaikuta negatiivisesti mihinkään näistä käyttäjistä.

Täältä opit suunnittelemaan ja toteuttamaan sujuvan tietokannan siirron pilveen.

Riippuvuuksien tutkiminen

Monimutkaisessa järjestelmässä komponentti toimii harvoin täysin itsenäisesti. Sen sijaan se kutsuu muita prosesseja ja komponentteja. Esimerkiksi tietokannat voivat olla riippuvaisia käyttäjätilejä isännöivistä hakemistopalveluista. Kun siirrät tietokannan pilveen, voitko käyttää kyseistä hakemistopalvelua? Jos ei, miten käyttäjät kirjautuvat sisään? Kun unohdat tällaisen riippuvuuden, tietokanta saattaa epäonnistua kokonaan.

Voit vähentää riskejä tarkistamalla, onko tietokantasi riippuvainen esimerkiksi seuraavista palveluista:

Hakemistopalvelut, kuten Active Directory.
Muut suojauksen pääsääntöjen säilöt.
Muut tietokannat.
Web-ohjelmointirajapinnat tai muut verkkopalvelut.

Muista myös, että muut osat voivat olla riippuvaisia tietokannastasi. Jos siirrät tietokantaa määrittämättä riippuvaisia osia uudelleen, mitä seurauksia sillä on? Jos esimerkiksi siirrät tuoteluettelotietokannan ja julkinen sivusto määrittää sen perusteella, mitä tuotteita käyttäjille esitetään, aiheuttaako siirto keskeytyksen palvelussa?

Tarkista, riippuuko jokin näistä komponenttityypeistä tietokannastasi:

Verkkosivustot ja verkko-API:t.
Asiakassovellukset, kuten mobiilisovellukset ja työpöytäohjelmistot.
Muut tietokannat.
Raportit.
Tietovarastot.

Voit tehdä nämä tarkistukset keskustelemalla kunkin tietokannan ja järjestelmäkomponentin sidosryhmien, järjestelmänvalvojien ja kehittäjien kanssa. Jos et ole varma, että ymmärrät järjestelmien toimintaa, tutustu dokumentaatioon ja harkitse testien, kuten verkkokaappausten, suorittamista toiminnan havaitsemiseksi.

Valmistaudu perääntymään

Kaikissa siirtoprojekteissa sinun tulee aina varautua epäonnistumiseen. Tietokannan siirtoprojektissa pilveen pahin mahdollisuus on, että uusi tietokanta ei ole käytettävissä eivätkä käyttäjät voi tehdä työtään. On tavallista, että tätä riskiä, jolla voi olla suuri vaikutus yrityksesi kannattavuuteen, lievennetään suunnittelemalla palaamista alkuperäiseen, muokkaamattomaan tietokantaan paikallisesti.

Harkitse varasuunnitelmaa varten seuraavaa:

Kuinka varmistaa, että voit palata tietokantaan, johon epäonnistunut siirto ei koske? On esimerkiksi erittäin suositeltavaa ottaa täydellinen tietokannan varmuuskopio juuri ennen siirron aloittamista.
Kuinka kauan tietokanta voi olla offline-tilassa, jos sinun on turvauduttava?
Kuinka paljon budjettia sinulla on varasuunnitelmalle? Onko sinulla esimerkiksi varaa kopioida tietokanta erilliselle varapalvelimelle? Jos näin on, voit kytkeä tämän palvelimen pois päältä juuri ennen siirtoa. Palataksesi taaksepäin käynnistät tämän palvelimen. Sinulla on välittömästi tietokanta, johon siirto ei vaikuta, ilman, että sitä tarvitsee palauttaa varmuuskopiosta.

Offline-siirto vs. online-siirto

Tietokannan siirtämiseen on vähintään kaksi vaihtoehtoa:

Note

Online-vaihtoehto ei ole tällä hetkellä käytettävissä MySQL-tietokannoissa Data Migration Servicessä.

Pysäytä järjestelmä, siirrä tietokanta ja määritä järjestelmä uudelleen ja käynnistä se uudelleen käyttämään uutta tietokantaa. Tämä on offline-siirto.
Pidä järjestelmä käynnissä, kun siirrät tietokannan uuteen sijaintiin, siirrä alkuperäisessä tietokannassa suoritettavat tapahtumat uuteen tietokantaan siirron aikana ja vaihda sitten sovellukset muodostamaan yhteys uuteen tietokantaan. Tämä on online-siirto.

Offline-siirron suorittaminen on yksinkertaisempaa, jolloin käyttäjät eivät voi muuttaa tietoja siirron aikana. Jos tietokantasi on kuitenkin varattu tai kriittinen organisaatiosi menestyksen kannalta, se ei ehkä ole mahdollista.

Offline-siirrot

Oletetaan, että tietokantasi tukee analyytikkoryhmää, joka työskentelee yhdellä aikavyöhykkeellä normaaleina aukioloaikoina. Tiimi ei yleensä työskentele viikonloppuisin. Perjantain klo 18.00 ja sunnuntain klo 9.00 välisenä aikana tietokantaa ei käytetä usein.

Tässä tilanteessa voit tehdä offline-siirron viikonloppuna seuraavasti:

Ota tietokanta offline-tilaan, kun kaikki tapahtumat on suoritettu perjantai-iltana.
Ota täydellinen varmuuskopio tai vienti tietokannasta.
Sammuta paikallinen palvelin ja säilytä se siltä varalta, että joudut palaamaan.
Palauta tietokanta kohdepilvijärjestelmään.
Tuo kohdejärjestelmä verkkoon.
Määritä asiakkaat uudelleen muodostamaan yhteys pilvitietokantaan.

Tässä tapauksessa offline-siirto on mahdollista, koska palvelun keskeytyksellä on pitkä aika vaikuttaa käyttäjiin vain vähän. Tänä aikana voit tehdä tietokannan täydellisen varmuuskopion ja palautuksen tietäen, että et menetä mitään muutoksia.

Muuttoliikkeet verkossa

Harkitse nyt toista tietokantaa, joka tukee myyntisovellusta. Myyntihenkilöstö on hajautettu ympäri maailmaa ja työskentelee myös viikonloppuisin. Ei ole vähäistä aktiivisuutta, tietokanta on aina varattu ja jos otat tietokannan offline-tilaan pitkäksi aikaa, se vaikuttaa käyttäjiin. Myyntitoiminta on liiketoimintakriittistä, joten palvelun keskeytyksellä on suora vaikutus organisaation tulokseen.

Tällaisissa tapauksissa harkitse online-siirron suorittamista. Online-siirrossa käyttökatkokset rajoittuvat uuteen tietokantaan siirtymiseen kuluvaan aikaan. Käytä työkalua, kuten Azure Data Migration Serviceä, online-siirron suorittamiseen. Online-siirroilla on seuraavat erot offline-siirtoihin verrattuna:

Et siirrä alkuperäistä tietokantaa offline-tilaan ennen varmuuskopioimista tai vientiä.
Kun siirto on käynnissä, muutokset koskevat vanhaa tietokantaa.
Siirtotyökalu varmistaa, että nämä muutokset kopioidaan uuteen tietokantaan ennen siirtymistä. Tämä saavutetaan usein määrittämällä vanha tietokanta uudelleen toistamaan muutokset uuteen.

Sovellusten siirto

Kun olet siirtänyt tietokannan, miten (ja milloin) sinun pitäisi siirtyä uuteen järjestelmään ja päivittää sovellukset käyttämään uutta tietokantaa? Saatat tehdä seuraavaa:

Siirrä sovellukset yksitellen uuteen tietokantaan.
Siirrä käyttäjien osajoukkoja.
Ota käyttöön molempien lähestymistapojen yhdistelmä.

Tarkoituksena on, että suoritat sovellusten siirron pienissä vaiheissa, jotka voidaan helposti peruuttaa, jos jokin menee pieleen. Riippumatta siitä, oletko noudattanut offline- vai online-lähestymistapaa tietokannan siirtoon, sinulla pitäisi silti olla toimiva määritys alkuperäisessä lähteessä. Teoriassa voit vaihtaa takaisin alkuperäiseen lähteeseen nopeasti. Mutta jos tiedot muuttuvat jatkuvasti, sinun on pohdittava, missä nämä muutokset on tehty.

Offline-siirrossa lähde ja kohteet ovat toisistaan riippumattomia. Käyttäjät ja sovellukset eivät ehkä enää näe yhtenäistä näkymää tiedoista. Transaktiojärjestelmässä tätä tilannetta ei todennäköisesti voida hyväksyä. Tässä tapauksessa sinun on ylläpidettävä jonkinlaista kaksisuuntaista replikointia tietokantojen välillä, kun molemmat järjestelmät pysyvät reaaliaikaisina. Vaihtoehtoisesti, jos sovelluksen tarkoituksena on luoda kuukausi- tai viikkoraportteja, luoda myyntiennusteita tai suorittaa muita tilastollisia toimintoja, tämä johdonmukaisuuden puute ei ehkä ole niin huolestuttavaa. Tällaiset sovellukset tarkastelevat dataa "pitkällä aikavälillä" sen sijaan, että ne olisivat riippuvaisia up-topäivämäärän tiedoista. Jälkimmäisessä tapauksessa transaktiosovellukset käyttävät uutta tietokantaa, kun taas raportointisovellukset liikkuvat hitaammin.
Online-siirrossa uusi tietokanta pidetään synkronoituna vanhan kanssa, yleensä jonkinlaisella replikoinnilla. Replikointiprosessi voi olla asynkroninen, joten siinä voi olla viive. Uuden tietokannan tietoihin tehtyjä muutoksia ei kuitenkaan levitetä takaisin vanhaan, mikä voi aiheuttaa ristiriitoja. Vanhaa tietokantaa vastaan suoritettava sovellus saattaa tehdä ristiriitaisen muutoksen uudessa tietokannassa muokattuihin tietoihin. Replikointi korvaa sokeasti muutoksen uudessa tietokannassa, mikä johtaa "päivityksen menetykseen".

Testausta koskevat lähestymistavat

Jos tietokannalla on kriittinen rooli liiketoiminnassasi, epäonnistumisen seuraukset voivat olla laajat. Jos haluat lisätä luottamustasi siihen, että näin ei tapahdu, harkitse suorituskykytestien suorittamista siirretylle tietokannalle varmistaaksesi, että se selviää käyttäjien sille mahdollisesti aiheuttamasta kuormituksesta ja reagoi nopeasti. Muista, että voi olla huippuhetkiä, jolloin kysyntä on paljon normaalia suurempi. Sinun on varmistettava, että siirretty järjestelmä käsittelee odotetun kuormituksen.

Suorita aina jonkinlainen regressiotestaus uudelle tietokannalle ennen kuin sallit käyttäjille pääsyn. Nämä testit varmistavat, että järjestelmän toiminta ja toiminnallisuus ovat oikein.

Lisäksi sinun tulee harkita "liotustestin" suorittamista. Liotustesti on kuormitustesti, jonka tarkoituksena on nähdä, kuinka järjestelmä kokonaisuutena toimii paineen alaisena. Liotustesti rasittaa uutta tietokantaa ja määrittää, onko se vakaa suuressa kysynnässä. Liotustesti suoritetaan merkittävän ajanjakson ajan, jotta nähdään, mitä tapahtuu, kun kysyntä jatkuu.

Kun olet todennut, että uusi järjestelmä on vakaa, voit aloittaa käyttäjien siirron. Saatat kuitenkin tarvita lisävarmuutta siitä, että käyttäjät pitävät uutta järjestelmää hyväksyttävänä. Tässä vaiheessa voit harkita "kanarialintutestausta". Kanarianlintutesti ohjaa läpinäkyvästi pienen osan käyttäjistä uuteen järjestelmään, mutta he eivät ole tietoisia siitä, että he käyttävät sitä. Se on eräänlainen sokkotesti, jonka tarkoituksena on auttaa sinua löytämään uuden järjestelmän ongelmat tai ongelmat. Seuraa näiden käyttäjien vastauksia ja tee tarvittavat muutokset.

Rinnakkaisten järjestelmien ylläpito

On useita syitä, miksi voit käyttää vanhaa paikallista tietokantaa rinnakkain uuden pilvitietokannan kanssa:

Testausjaksot. Kuten edellisessä aiheessa huomasit, on hyvä idea suorittaa kanarialintutestejä siirretylle tietokannalle sen toimivuuden, vakauden ja kapasiteetin arvioimiseksi, ennen kuin käytät sitä ihmisten tukemiseen. Paikallisen järjestelmän rinnakkainen ylläpito antaa sinulle nopean tavan palauttaa käyttäjät vanhaan järjestelmään, jos uudessa järjestelmässä on ongelmia.
Vaiheittaiset siirrot. Yksi tapa lieventää odottamattomien vikojen vaikutusta tuotantoon on siirtää ensin pieni määrä käyttäjiä uuteen järjestelmään ja seurata tuloksia. Jos kaikki sujuu ongelmitta, voit siirtää muita käyttäjäryhmiä, kun luotat uuteen tietokantaan. Voit siirtää käyttäjiä aakkosjärjestyksessä, osaston, sijainnin tai roolin mukaan, kunnes he ovat kaikki uudessa tietokannassa.
Hajanaisia muuttoliikkeitä. Toinen tapa on segmentoida siirto ei käyttäjän vaan työmäärän mukaan. Voit esimerkiksi siirtää henkilöstöhallintoa tukevat tietokantataulukot ennen myyntiä tukevia taulukoita.

Kaikissa näissä tapauksissa on ajanjakso, jolloin vanha paikallinen tietokanta toimii rinnakkain uuden pilvitietokannan kanssa. Sinun on varmistettava, että vanhaan tietokantaan tehdyt muutokset otetaan käyttöön myös uudessa tietokannassa ja että ne kulkevat vastakkaiseen suuntaan. Voit suorittaa tämän synkronoinnin komentosarjan tai käyttää työkalua, kuten Azure Data Migration Service.

Jos päätät ylläpitää rinnakkaisia tietokantoja ja synkronoida muutokset, kysy itseltäsi seuraavat kysymykset:

Konfliktien ratkaiseminen. Onko todennäköistä, että paikallisen rivin muutos tapahtuu samaan aikaan kuin sama rivi pilvipalvelussa? Tämä loisi ristiriidan, jossa on epäselvää, mikä muutos pitäisi säilyttää. Miten ratkaisisit tällaiset ristiriidat?
Verkkoliikenne. Kuinka paljon verkkoliikennettä syntyy, kun muutokset synkronoidaan tietokantojen välillä? Onko sinulla tarpeeksi verkkokapasiteettia tähän liikenteeseen?
Viive. Kun yhdessä tietokannassa tapahtuu muutos, mikä viive (jos sellainen on) on hyväksyttävä ennen kuin muutos saavuttaa toisen tietokannan? Esimerkiksi tuoteluettelossa voit ehkä odottaa jopa päivän, ennen kuin uudet tuotteet näkyvät kaikille käyttäjille. Jos tietokanta kuitenkin sisältää kriittisiä transaktiotietoja, kuten valuuttakursseja, nämä tiedot tulisi synkronoida paljon useammin, ellei jopa välittömästi.

Hajanainen muuttoliike

Hajanaisessa siirrossa jaat kokonaisen järjestelmän työkuormiin ja siirrät yhden työkuorman kerrallaan.

Useita tietokantoja

Monimutkainen järjestelmä voi sisältää useita tietokantoja, jotka tukevat useita kuormituksia. Esimerkiksi henkilöstöhallinto voi käyttää StaffDB-tietokantaa , kun taas myyntiryhmällä voi olla mobiilisovelluksia, jotka tekevät kyselyjä sekä ProductCatalogDB-tietokannasta että OrdersDB-tietokannasta .

Voit tietysti siirtää koko tietokantajärjestelmän pilveen yhdellä kertaa. Tämä voi olla yksinkertaisempaa, koska sinun ei tarvitse suorittaa tietokantoja sekä paikallisesti että pilvipalvelussa. Sinun ei tarvitse miettiä, miten nämä tietokannat kommunikoivat siirron aikana. Epäonnistumisen riskit ovat kuitenkin suuremmat. Yksittäinen ongelma voi vaikuttaa sekä henkilöstöhallintotiimiin että myyntitiimiin.

Harkitse näiden riskien lieventämistä keskisuurissa ja suurissa tietokantajärjestelmissä suorittamalla osittainen siirto, jossa siirrät yhden kuormituksen kerrallaan. Tässä esimerkissä voit harkita ensin StaffDB-tietokannan siirtämistä, koska virheeseen liittyvät ongelmat rajoittuisivat henkilöstötiimiin eivätkä estäisi sinua vastaanottamasta tilauksia. Ratkaisemalla StaffDB:n siirron yhteydessä ilmenevät ongelmat opit oppitunteja, jotka koskevat muita kuormitussiirtoja.

Seuraavaksi voit harkita tuoteluettelon kuormituksen siirtämistä pilveen. Jos teet niin, harkitse esimerkiksi seuraavia kysymyksiä:

Miten varmistat, että luetteloon äskettäin lisätyt tuotteet ovat tilattavissa?
Pitääkö sinun synkronoida tietoja OrdersDB-tietokannan kanssa, joka pysyy paikallisena?
Mikä viive on hyväksyttävä, jotta uudet tuotteet pääsevät OrdersDB-tietokantaan tuoteluettelosta?

Yksittäisen tietokannan hajanaiset siirrot

Vaikka sinulla olisi vain yksi tietokanta, joka tukee kaikkia työkuormia, voit silti harkita vaiheittaista siirtoa. Voit esimerkiksi jakaa tietokannan osiin seuraavasti:

HR-toimintoja tukevat taulukot.
Myyntiä tukevat taulukot.
Taulukot, jotka tukevat analysointia ja raportointia.

Jos siirrät ensin HR-toimintotaulukot, ilmenevät ongelmat vaikuttavat vain henkilöstöhallintohenkilöstöön. Myynti- ja data-analyytikot jatkavat työskentelyä vanhan tietokannan parissa keskeytyksettä.

Ennen kuin suoritat osittaisen siirron, sinun on ymmärrettävä tietokannat ja miten sovellukset käyttävät niitä. Jotkin tietokannan taulukot voivat esimerkiksi tukea sekä myyntiä että raportointia. Tämä tarkoittaa, että työkuormia ei voi jakaa siististi. Nämä taulukot on synkronoitava paikallisten ja pilvitietokantojen välillä, kunnes kaikki kuormitukset on siirretty.

Turvallisuusongelmat

Tietokannat voivat sisältää arkaluonteisia tietoja, kuten tuotetietoja, henkilökohtaisia henkilöstötietoja ja maksutietoja, joten tietoturva on aina etusijalla. Sinun on päätettävä, miten nämä tiedot suojataan siirron aikana ja uudessa tietokannassa.

Palomuurin suojaus

Internetiin yhdistetyssä sovelluksessa tietokantapalvelimet on yleensä suojattu vähintään kahdella palomuurilla. Ensimmäinen palomuuri erottaa Internetin käyttöliittymäpalvelimista – jos nämä palvelimet isännöivät esimerkiksi verkkosivustoja tai verkko-ohjelmointirajapintoja. Vain TCP-portin 80 tulee olla auki ulkopalomuurissa, mutta tämän portin on oltava avoinna kaikille lähde-IP-osoitteille, paitsi estetyille osoitteille.

Toinen palomuuri erottaa käyttöliittymäpalvelimet tietokantapalvelimista. Tietokantapalvelu kannattaa julkaista yksityisessä porttinumerossa, joka ei ole ulkomaailman tiedossa. Avaa toisessa palomuurissa tämä porttinumero vain edustapalvelimien IP-osoitteille. Tämä järjestely estää suoran viestinnän pahantahtoiselta Internetin käyttäjältä tietokantapalvelimille.

Jos aiot siirtää tietokantapalvelimia Azure-näennäiskoneisiin, käytä palomuurisääntöjen replikointiin näennäisverkkoa, jossa on verkon käyttöoikeusryhmiä (NSG). Jos käytät Azure Database for MySQL:ää, Azure Database for MariaDB:tä tai Azure Database for PostgreSQL:ää, voit luoda palomuurisääntöjä tietokannan suojaamiseksi käyttämällä palvelimen Yhteyden suojaus -sivua Azure-portaalissa.

Todentaminen ja valtuutus

Useimmissa tietokannoissa sinun on valvottava tarkasti, kuka käyttää ja muokkaa mitäkin tietoja. Tämä ohjausobjekti edellyttää, että käyttäjät tunnistetaan, kun he muodostavat yhteyden tietokantaan. Tätä prosessia kutsutaan todennukseksi , ja se tehdään yleensä käyttäjätunnuksella ja salasanalla. Tietokantajärjestelmät, kuten MySQL, MariaDB ja PostgreSQL, tarjoavat omat todennusmekanisminsa. Sinun on varmistettava, että jatkat käyttäjien todentamista turvallisesti, kun siirrät järjestelmäsi pilvipalveluun.

Note

Azure Database for MySQL-, Azure Database for MariaDB- ja Azure Database for PostgreSQL -palvelut emuloivat perinteistä MySQL-, MariaDB- ja PostgreSQL-todennusta.

Kun tiedät, kuka käyttäjä on, sinun on annettava hänelle oikeudet suorittaa työhönsä kuuluvat tehtävät. Tätä prosessia kutsutaan valtuutukseksi.

Tietokannan siirtoprojektia varten sinun on varmistettava, että käyttäjät on valtuutettu oikein pilvitietokantaan:

Selvitä, mihin käyttäjätilit on tallennettu paikallisessa järjestelmässä. MySQL:ssä käyttäjätunnukset tallennetaan yleensä tietokannan user taulukkoonmysql, mutta se on mahdollista integroida esimerkiksi Active Directoryyn tallennettuihin käyttäjätileihin.
Hanki luettelo kaikista käyttäjätileistä. Esimerkiksi MySQL:ssä voit käyttää tätä komentoa:
```
SELECT host, user FROM mysql.user;
```
Selvitä kunkin käyttäjätilin osalta, mitä pääsyä heillä on tietokantaan. Esimerkiksi MySQL:ssä voit käyttää tätä komentoa dbadmin@on-premises-host käyttäjätilille:
```
SHOW GRANTS FOR 'dbadmin'@'on-premises-host';
```
Luo kukin käyttäjätili uudelleen pilvitietokannassa. Esimerkiksi MySQL:ssä voit käyttää tätä komentoa uuden tilin luomiseen:
```
CREATE USER 'dbadmin'@'cloud-host'
```
Valtuuta jokainen käyttäjätili oikealle käyttöoikeustasolle pilvitietokannassa. Esimerkiksi MySQL:ssä voit käyttää tätä komentoa salliaksesi käyttäjän käyttää koko tietokantaa:
```
GRANT USAGE ON *.* TO 'dbadmin'@'cloud-host'
```

Salaus

Kun tietoja lähetetään verkon kautta, se voidaan siepata niin sanotulla "man-in-the-middle" -hyökkäyksellä. Tämän estämiseksi sekä Azure Database for MySQL, Azure Database for MariaDB että Azure Database for PostgreSQL tukevat SSL (Secure Sockets Layer) -palvelua viestinnän salaamiseen. SSL on oletusarvoisesti pakotettu, ja on erittäin suositeltavaa, että et muuta tätä asetusta.

Sinun on ehkä muutettava asiakassovellusten yhteysasetuksia SSL-salauksen käyttämiseksi. Keskustele tästä aiheesta kehittäjien kanssa ja määritä mahdolliset tarvittavat muutokset.

Seuranta ja hallinta

Tietokannan siirron suunnittelussa on pohdittava, miten tietokannan järjestelmänvalvojat jatkavat tehtäviensä suorittamista siirron jälkeen.

Monitoring

Paikalliset tietokannan järjestelmänvalvojat ovat tottuneet valvomaan säännöllisesti havaitakseen ongelmia, kuten laitteiston pullonkauloja tai kilpailua verkkoon pääsystä. He valvovat, että he voivat korjata mahdolliset ongelmat ennen kuin tuottavuus heikkenee. Voit odottaa, että mikä tahansa tietokanta, jota ei valvota säännöllisesti, alkaa aiheuttaa ongelmia ennemmin tai myöhemmin.

Sinun tulisi noudattaa täsmälleen samaa lähestymistapaa pilvitietokantoihin. Ongelmia voi olla helpompi ratkaista Azuren kaltaisessa PaaS-järjestelmässä, koska voit lisätä resursseja ostamatta, määrittämättä ja määrittämättä mitään laitteistoa. Sinun on kuitenkin edelleen havaittava kehittyvät ongelmat, joten seuranta on tärkeä osa päivittäisiä tehtäviäsi.

Ennen kuin siirrät tietokantoja pilveen, selvitä, mitä valvontatyökaluja järjestelmänvalvojasi käyttävät tällä hetkellä. Jos nämä työkalut ovat yhteensopivia ehdottamasi pilvipohjaisen ratkaisun kanssa, sinun on ehkä vain yhdistettävä ne uudelleen siirrettyihin tietokantoihin. Jos ei, sinun on tutkittava vaihtoehtoja.

Muista, että Azure sisältää joukon suorituskyvyn valvontatyökaluja ja kerää monenlaisia suorituskykylaskureita ja lokitietoja. Voit näyttää nämä tiedot käyttämällä koontinäyttöjä ja kaavioita Azure-portaalissa määrittämällä Azure Monitorin. Luot mukautettuja kaavioita, taulukoita ja raportteja, jotka on suunniteltu erityisesti järjestelmänvalvojien tarpeisiin.

Hallinta

Tietokannan järjestelmänvalvojat käyttävät ensisijaisia työkaluja tietokannan rakenteen ja sisällön muuttamiseen paikallisesti. Jos he käyttävät samoja työkaluja siirron jälkeen, voit edelleen hyötyä heidän asiantuntemuksestaan. Aloita arvioimalla, onko olemassa oleva työkalusarja yhteensopiva ehdotetun pilvipalvelussa isännöidyn tietokannan kanssa. Monet työkalut ovat yhteensopivia, koska ne perustuvat laajalti hyväksyttyihin standardeihin, kuten SQL:ään, mutta on tärkeää varmistaa yhteensopivuus. Jos nykyiset hallintatyökalut eivät toimi siirron jälkeen, yritä selvittää vaihtoehtoja järjestelmänvalvojien kanssa.

Azure sisältää useita työkaluja, joiden avulla voit hallita MySQL-, MariaDB- ja PostgreSQL-tietokantoja:

Azure-portaali. Tässä sivustossa on tehokkaita toimintoja, joiden avulla voit määrittää, valvoa ja hallita tietokantoja – ja kaikkia muita resursseja, joita saatat luoda Azure-pilvipalveluun.
Azure PowerShell. Tämä on komentosarjojen suoritusympäristö ja kieli, jolla on laaja joukko komentoja. Käytä PowerShelliä, joka on saatavilla Windows- ja Linux-ympäristöille, monimutkaisten tietokannan hallintatehtävien automatisointiin.
Azure CLI. Tämä on komentoriviliittymä Azureen. Sen avulla voit hallita palveluita ja resursseja Azuressa. Voit käyttää CLI:tä Windows- ja Linux-liittymäympäristöissä sekä Bash-komentosarjoissa.

Palaute

Onko tästä sivusta apua?