Vertaa isännöintimalleja niiden antamien toimintavastuiden ja mahdollistaman arkkitehtuurin kautta. Pilven skaala, virtuaalikone ja oma laitteisto kuvaavat järjestelmän eri osa-alueita; mikään niistä yksinään ei todista yksityisyyttä, kustannuksia tai palautumiskäyttäytymistä.
Aloita työstä, jonka haluat jonkun omistavan
Isännöintipäätös antaa toimintatyötä sekä laskentaresursseja. Yksi projekti tarvitsee tilin, joka pyörittää tavanomaista verkkosivustoa; toinen tarvitsee hallinnan käyttöjärjestelmän paketeista ja taustaprosesseista. Kolmas tarvitsee tietokanta-alustan, jonka ylläpito hoidetaan tietyn palvelusopimuksen mukaisesti. Luettele nämä vastuut ensin ja sen jälkeen ihmiset, jotka voivat ylläpitää niitä.
Jaettu isännöinti tarjoaa tyypillisesti tilitason ympäristön. VPS tarjoaa vieraskäyttöjärjestelmän, kun taas oma laitteisto siirtää koneen rajan fyysiseen palvelimeen. Hallinnoitu on erillinen kysymys: tuotemerkintä ei kerro, kuka asentaa korjaukset, palauttaa tiedot tai tutkii häiriön. Kysy hallinnan laajuutta ja palautusmenettelyä sen sijaan, että pitäisit sitä yleisenä ominaisuutena.
Ymmärrä, mitä pilvi lisää vertailuun
NIST kuvaa pilvilaskentaa ominaisuuksilla, kuten kysyntäpohjainen käyttö, resurssien yhdistäminen, joustavuus ja mitattu palvelu. Virtuaalikone voi olla yksi pilvialustan komponentti, joten VPS ja pilvi eivät ole toisensa poissulkevia teknologioita. Hyödyllinen vertailu tehdään tarjottujen yksittäisten palvelujen välillä: kiinteä virtuaalikone, joustava laivue tai hallinnoitujen palvelujen ympärille rakennettu sovellus.
Hyperscaler on alan termi palveluntarjoajalle, joka käyttää infrastruktuuria ja palvelualustoja erittäin suuressa mittakaavassa. Tämä mittakaava voi tarjota laajan valikoiman käyttöönottotyökaluja ja maantieteellisiä vaihtoehtoja; se ei kerro, täyttääkö tietty arkkitehtuuri tarpeesi. Arvioi kunkin komponentin alue, palveluriippuvuudet, identiteettimalli ja sopimus. Sekä pienempi palveluntarjoaja että suuri alusta edellyttävät selvitystä siitä, minne tiedot menevät.
| Toimintamalli | Projektin käytettävissä oleva hallinta | Kysymys ennen valintaa |
|---|---|---|
| Jaetun isännöinnin tili | Sivuston asetukset tilin laajuudessa | Sopiiko ajoympäristö sovellukselle? |
| Virtuaalikone | Vieraskäyttöjärjestelmä ja asennetut palvelut | Kuka ylläpitää ja palauttaa vieraan? |
| Oma kone | Fyysisen palvelimen raja | Perusteleeko työkuorma tämän rajan? |
| Hallinnoitu pilvipalvelu | Palvelun API ja tuetut asetukset | Mikä jää asiakkaan vastuulle? |
Valitse arkkitehtuuri, joka voi palautua
Yksi kone voi olla järkevä aloituspiste pienelle sovellukselle, kun sen palautusvaatimukset sallivat palautuksen tai suunnitellun huoltokatkon. Toisen sovellusnoodin lisääminen muuttaa suunnittelua vain, jos liikenteen reititys, istunnot ja pysyvä data toimivat oikein molemmissa. Kaksi palvelinta, joissa on sama puutteellinen palautussuunnitelma, ovat edelleen puutteellinen palautussuunnitelma.
Hajautettu tallennus havainnollistaa tätä eroa. Ohjelmistot, kuten Ceph, jakavat tallennustyön klusterin kesken ja tarjoavat objekti-, lohko- ja tiedostorajapinnat. Replikointi tai koodausmenetelmät voivat auttaa sietämään tiettyjä laitteistovikoja, mutta klusteri tarvitsee myös kapasiteettia palautusta ja tasapainotusta varten. Hajautettu reaaliaikainen kopio ei korvaa riippumatonta varmuuskopiota. Päätä, miten kirjoitukset käyttäytyvät verkon osittuessa, ja testaa valitsemasi toteutuksen kannalta olennaiset vikatapaukset.
Vertaa koko käyttöbudjettia
Kirjoita budjetti työkuormana: normaali liikenne, kiireinen jakso, tallennettu data, varmuuskopioiden säilytys ja palautukseen tarvittava siirto. Sisällytä maksullinen ohjelmisto, ulkoiset rajapinnat, ylläpitoaika ja tietojen uudelleen siirtämisen kustannus. Aloituksen kuukausisumma ja käyttöpohjainen arvio vastaavat eri kysymyksiin. Vertaa niitä samalta ajanjaksolta ja pidä oletukset tuloksen rinnalla.
Tunnista suurella pilvialustalla jokainen palvelu, jota tarvitaan sovelluksen pitämiseen käynnissä. Sisällytä VPS-palvelimeen työ, jonka hallinnoidut palvelut muuten ottaisivat hoitaakseen. Kumpikaan lähestymistapa ei ole automaattisesti halvempi. Aloita pienestä edustavasta käyttöönotosta tai dokumentoidusta tarjouksesta ja tarkista sitten todellinen lasku mallia vasten. Varaa tilaa palautusliikenteelle ja tilapäiselle siirtokapasiteetille sen sijaan, että budjetoisit vain vakaan tilan.
Käsittele yksityisyyttä riippuvuuskarttana
Koneen alue on yksi merkintä laajemmassa kartassa. Todennus, valvonta, tukityökalut, varmuuskopiot ja mallirajapinnat voivat toimia erillisten palvelujen kautta. Kirjaa, mitä kukin vastaanottaa, kuka voi käyttää sitä ja kuinka kauan se säilytetään. AWS:n jaetun vastuun malli on yksi esimerkki palveluntarjoajasta, joka erottaa infrastruktuuritehtävänsä asiakkaan tehtävistä; laajuus muuttuu palvelun mukaan.
Käytä tätä eroa palveluntarjoajien vertailussa viemättä yhden palveluntarjoajan velvoitteita toiseen sopimukseen. SwissOctet-kokoonpano kuvaa isännöintisijaintia ja lueteltuja resursseja. Se ei vahvista myöhemmin lisäämiesi integraatioiden sijaintia. Minimoi kunkin riippuvuuden vastaanottamat tiedot, turvaa ylläpito ja varmista varmuuskopiokohteet ennen kuin esität väitteen oman sovelluksesi tietojen kulkureitistä.
Käytä siirtopolkua osana päätöstä
Tarkista, miten voit viedä sovellustiedot, kokoonpanon ja identiteetit. Tavanomainen sovellus virtuaalikoneella voi olla suoraviivainen siirtää, kun taas palvelukohtainen tietokanta tai tapahtumajärjestelmä voi vaatia mukauttamista. Siirrettävyys riippuu myös toimintatietämyksestä: varmuuskopio, jota kukaan ei osaa palauttaa, on heikko poistumissuunnitelma, vaikka sen muoto olisi avoin.
Ensimmäiseen SwissOctet-lyhytlistaan vertaa Canvasia, kun tilitason verkkoympäristö sopii, Vectoria vieraskäyttöjärjestelmän hallintaan ja Metal-valikoimia, kun fyysinen raja on tärkeä. Tallennukseen painottuvat vaihtoehdot tukevat eri kapasiteettikysymystä, eikä niitä pidä kuvata hallinnoituna hajautettuna klusterina. Pidä arkkitehtuuri riittävän pienenä ylläpidettäväksi ja lisää alustan monimutkaisuutta, kun se vastaa testattua vaatimusta eikä kuviteltua tulevaa skaalaa.
Käytännön tarkistuslistasi.
- Määritä ylläpidon ja palautuksen omistajuus.
- Erota virtuaalikone laajemmasta pilvialustasta.
- Budjetoi riippuvuudet, siirto ja ylläpito.
- Testaa vikaraja ennen noodien lisäämistä.
- Kirjaa toimiva tietojen vienti- ja siirtopolku.
Olennaiset yksityiskohdat.
Voiko VPS olla osa pilvialustaa?+
Kyllä. Virtuaalikone voi olla pilvipalvelu. Vertaa todellista resurssi-, skaalaus- ja hallintamallia sen sijaan, että olettaisit nimien kuvaavan toisensa poissulkevia teknologioita.
Korvaako hajautettu tallennus varmuuskopiot?+
Ei. Reaaliaikainen redundanssi käsittelee valittuja komponenttivikoja. Riippumaton varmuuskopio ja palautustesti käsittelevät muita vikoja, kuten poistamista ja vaurioitunutta sovellusdataa.
Onko suuri pilvi aina huono yksityisyysvalinta?+
Ei. Arvioi tietyt palvelut, tietovirrat ja sopimusperusteiset hallintakeinot. Pelkkä palveluntarjoajan koko ei ratkaise arkkitehtuurin soveltuvuutta.
Mene lähteelle.
Nämä lähteet tukevat tämän oppaan teknisiä käsitteitä. Noudata ajantasaisia dokumentaatioita ennen tuotantojärjestelmän muuttamista.
- NIST SP 800-145: Pilvilaskennan määritelmä nvlpubs.nist.gov
- AWS: Jaetun vastuun malli aws.amazon.com
- Ceph: Tallennusarkkitehtuuri docs.ceph.com
- Ceph: Koodausmenetelmät docs.ceph.com
Toimituksellinen ohjaus: SwissOctet. Esimerkit ovat havainnollistavia. Palvelumääritykset, saatavilla olevat vaihtoehdot ja sopimusehdot on tarkistettava erikseen.