Kuinka siirtää paikallinen palvelin AWS:ään (Yksinkertainen toimintasuunnitelma)

Johdanto

Paikallisesta AWS:ään siirtymiset epäonnistuvat harvemmin laskentatehon vuoksi ja enemmän suunnitteluvajeiden takia: epäselvät siirtymistavoitteet, huomiotta jääneet riippuvuudet ja kiireiset testaukset. Tämä opas pitää prosessin helppona seurata samalla, kun se pysyy toiminnassa. Määrittelet, miltä menestys näyttää, valmistelet minimaalisen laskeutumisen, suoritat AWS MGN -testilanseerauksia, siirryt luottavaisesti ja optimoit kuormituksen sen jälkeen, kun se on aktiivinen.

Mitä sinun tulisi päättää ennen kuin siirrät mitään?

Mikä migraatiostrategia sopii tälle palvelimelle (AWS:n "7 Rs")?

Nopein tapa hukata aikaa on siirtää väärä asia. Ennen kuin asennat minkään agentin, päätä, mikä siirtostrategia palvelimelle kuuluu, jotta et siirrä jotain, joka tulisi eläkkeelle laittaa tai korvata. Käytännössä monet tiimit aloittavat siirtämällä nopeuden vuoksi ja optimoivat myöhemmin, kun työkuorma on vakaa AWS:ssä.

Kuitenkin, se toimii vain, kun palvelin on hyvä "sellaisenaan" ehdokas eikä aiheuta kalliita teknisiä velkoja heti siirron jälkeen. Käytännön päätöksentekotavat:

• Uudelleen isännöinti: liiku nopeasti vähäisillä muutoksilla, kun aikaa on vähän.
• Uudelleenalustaminen: pidä sovellus, mutta tee pieniä säätöjä AWS:lle sopivaksi.
• Refaktorointi: varaa resursseja liiketoiminnallisesti kriittisille erottajille.
• Uudelleenosto: korvata sillä SaaS sen sijaan, että siirrettäisiin palvelinta.
• Eläke/Säilytä: poista käyttämättömät järjestelmät tai pidä rajoitetut työkuormat paikallisina.

Hyödyllinen sisäinen tarkistuskohta on kysyä, onko kuormituksella "pilv tulevaisuus." Jos palvelin myöhemmin puretaan hallinnoituihin palveluihin tai kontteihin, dokumentoi se nyt ja käsittele uudelleen isännöintiä väliaikaisena vaiheena sen sijaan, että se olisi pysyvä suunnittelu.

Mitä ovat RTO/RPO, seisokkiaika ja palautuslaatikot?

Leikkaukset onnistuvat, kun menestys on mitattavissa. Määrittele hyväksyttävä seisokkiaika ja tietohävikki, ja kirjoita sitten ylös ehdot, jotka pakottavat palauttamaan. Tämä pitää migraation tavoitteena ja estää tiimejä improvisoimasta leikkausikkunan aikana. Se auttaa myös liiketoimintojen sidosryhmiä hyväksymään, koska he näkevät tarkalleen, mikä riski hyväksytään.

Määritä ja dokumentoi:

• RTO: suurin hyväksyttävä käyttökatko.
• RPO: suurin hyväksyttävä tietohävikki.
• Käyttökatkoikkuna: kun sinulle sallitaan vaihtaa tuotantoliikennettä.
• Palautusliipaisimet: erityiset vikaehdot (autentikointikatkos, epäonnistuneet tapahtumat, tietojen epäsuhta).
• Siirtymismekanismi: DNS-käännös, kuormantasausvaihde, reititys/palomuuri muutokset.

Jotta palautussuunnitelma pysyisi realistisena, määrittele, kuka omistaa kunkin toimenpiteen siirtymävaiheessa. Esimerkiksi yksi henkilö omistaa DNS-muutokset, yksi omistaa sovelluksen vahvistamisen ja yksi omistaa "palautuspäätöksen" yllä olevien laukaisimien perusteella.

Mitä tarvitset valmiiksi AWS:ssä ja paikallisessa ympäristössä ensin?

Yhteys- ja palomuuriperusteet replikaatiota varten

Replikaatio toimii vain, jos lähdeympäristö voi saavuttaa AWS:n johdonmukaisesti. Yleisimmät esteet ovat tiukat ulosmenokontrollit, välityspalvelimet ja TLS-tarkastus, jotka häiritsevät ulospäin suuntautuvaa HTTPS-liikennettä. Varmista yhteys aikaisessa vaiheessa ja pidä verkkopolku vakaana alkuperäisen replikaation ja testilaukausten aikana. Monissa ympäristöissä replikaatiota ei "estetä" suoraan; sen sijaan satunnaiset katkokset tai pakettitarkastus aiheuttavat epävakaata käyttäytymistä, jota on vaikea diagnosoida myöhemmin.

Yleiset yhteysmallit:

• Julkinen internet-lähtö (helpoin, kun se on sallittu)
• Verkosta-verkkoon VPN (yleinen yksityiseen yhteyteen)
• Suora yhteys (ennakoitavampi suuremmille ympäristöille)

Esikatsastukset:

• Ulkopuolinen HTTPS toimii luotettavasti lähdeverkosta.
• Proxy-käyttäytyminen on ymmärretty ja testattu siirtoprosessin yhteydessä.
• Turvatiimit hyväksyvät vaaditun ulosmenon siirtosikkunalle.

Jos ympäristösi on erittäin suljettu, lisää lyhyt "verkkotodennus" vaihe aalto suunnitelmaasi: validoi päätepisteet yhdeltä pilottipalvelimelta, ja toista sitten tämä tarkka sääntöjoukko loppua aaltoa varten.

Minimal AWS laskeutumisalustan tarkistuslista

Et tarvitse täydellistä laskeutumisaluetta aloittaaksesi, mutta tarvitset johdonmukaisen kohteen, joka ei muutu aallon aikana. Pidä rakennus minimissä, mutta harkittuna, jotta testaus heijastaa sitä, miltä siirtyminen näyttää. Monet siirtoon liittyvät ongelmat johtuvat "väliaikaisista" verkkopolkuista, jotka muuttuvat pysyviksi, koska kenelläkään ei ole aikaa rakentaa niitä uudelleen lanseerauksen jälkeen.

Minimialueen elementit:

• [A] A VPC ja aliverkot missä instanssit käynnistyvät (usein erilliset testi- ja tuotantoympäristöt)
• Turvaryhmät sovelluksen todellisiin työnkulkuihin kohdistettu (vältä "avaa nyt, korjaa myöhemmin")
• IAM valmiina siirtotoimiin ja toisen päivän pääsyyn ja työkaluihin
• Perus merkitseminen omistajuuden ja kustannusten seuranta on selkeää siirtymisen jälkeen

Se auttaa myös päättämään varhain, miten ylläpitäjät pääsevät käsiksi instansseihin (bastion, VPN , SSM) ja miten ulospäin suuntautuva internet-yhteys tarjotaan (NAT-portti, välityspalvelin). Nämä valinnat vaikuttavat päivityksiin, valvontatoimintoihin ja vianetsintään ensimmäisenä päivänä.

Lähdepalvelimen valmiustarkistuslista

Puhdas siirtyminen riippuu puhtaasta lähteestä. Vahvista, että työkuorma on yhteensopiva valitsemasi menetelmän kanssa, ja tunnista sitten kaikki, mikä riippuu paikallisista oletuksista, jotka muuttuvat AWS:ssä. Tässä vaiheessa voit myös merkitä "erityistapaukset", jotka saattavat vaatia erilaista järjestystä. Esimerkiksi tiedostopalvelin, jolla on voimakasta kirjoitustoimintaa, saattaa tarvita tiukempaa siirtymisikkunaa ja tiukempaa vahvistusta avoimille tiedostoille ja jakamisille.

Valmiustarkastukset, jotka estävät yllätyksiä:

• OS/kuormituksen yhteensopivuus siirtomenetelmän kanssa
• Riittävä levytila ja vakaa I/O replikaatioylijäämälle
• Riippuvuudet kartoitettu: DNS , AD/LDAP , sisäinen PKI/sertifikaatit , tietokannat, osakkeet
• Piilotettu hauraus: kovakoodatut IP-osoitteet, vanhentunut TLS, epätavalliset aikataulutetut tehtävät
• Erityistapaukset merkitty aikaisin: verkkotunnusohjaimet, klusterit, laitteet, dongle-lisensointi

Ennen tämän vaiheen lopettamista, tallenna "täytyy pysyä samana" -kohteet, kuten isäntänimi, IP-osoitevaatimukset tai sertifikaattisidokset, koska nämä vaikuttavat suoraan AWS-käynnistysasetuksiisi ja siirtymisjärjestykseesi.

Kuinka siirrät palvelimen AWS:ään AWS MGN:n avulla?

Alusta MGN ja määritä replikaation oletusasetukset

Aloita AWS MGN: n määrittäminen alueella, jossa palvelin toimii, ja määritä sitten replikaation oletusasetukset, jotta aallon suoritus pysyy johdonmukaisena. Vakaa malli vähentää palvelinkohtaisia vaihteluita ja tekee vianetsinnästä toistettavaa. Ajattele tätä standardimenettelynäsi replikaatiolle, samankaltaisena kuin kultakuva virtualisoidussa ympäristössä.

Aseta replikaation oletusarvot etukäteen:

• Kohdeverkon strategia ja verkon sijoittaminen
• Käynnistettyjen instanssien turvallisuusryhmän peruslinja
• Tallennuskäyttäytyminen (tilan kartoitus, salauksen odotukset)
• Replikoinnin rajoittaminen tuotantoliikenteen suojaamiseksi

Jos tiedät jo, että tuotanto vaatii erilaisia asetuksia kuin testaus, määrittele nämä erot selkeästi. Näin testikäynnistykset pysyvät edustavina ilman, että tuotantoverkot altistuvat liian aikaisin.

Asenna agentti ja suorita aloitussynkronointi

Asenna replikaatioagentti lähdepalvelimelle ja varmista, että se rekisteröityy onnistuneesti. Alkuperäinen synkronointi on se vaihe, jossa epävakaus maksaa sinulle eniten, joten vältä tarpeettomia muutoksia ja seuraa replikaation terveyttä tarkasti. Tässä vaiheessa tiimit hyötyvät myös "tunnetun hyvän" asennusprosessin dokumentoinnista, jotta he eivät ratkaise samoja ongelmia jokaisessa aallossa.

Toiminnalliset ohjeet:

• Pidä palvelin vakaana alkuperäisen replikaation aikana (vältä uudelleenkäynnistyksiä, jos mahdollista)
• Valvo replikaation tilaa ja käsittele virheet heti.
• Dokumentoi asennusmenetelmä, jotta tulevat erät ovat johdonmukaisia.

Alkuperäisen synkronoinnin aikana on tärkeää valvoa paitsi migraatiokonsolia myös palvelimen suorituskykyä. Replikoinnin ylikuormitus voi paljastaa tallennuspullonkauloja tai levyvikoja, jotka olivat aiemmin piilossa paikallisessa ympäristössä.

Käynnistä testiversio ja validoi

Testikäynnistys muuttaa oletukset todisteiksi. Käynnistä testiversio ja validoi sovelluksen terveys päästä päähän, ei vain käynnistymisen onnistumista. Käytä tarkistuslistaa, jotta testaus on toistettavaa palvelimien ja aaltojen välillä. Jos loppukäyttäjät yhdistävät kautta TSplus Etäyhteys sisällytä pääsypolun tarkistus validointiin. Johdonmukaisuus on tärkeää, koska se mahdollistaa tulosten vertailun työkuormien välillä ja mallien havaitsemisen, kuten DNS-nimeämisongelmat, jotka vaikuttavat useisiin palvelimiin.

Vähimmäisvaatimusten tarkistuslista:

• Käynnistys valmistuu ja palvelut käynnistyvät puhtaasti
• Sovelluksen savutestit läpäisevät keskeiset työnkulut
• Todennus toimii (AD/LDAP/paikallinen)
• Tietopolut toimivat (DB-yhteydet, tiedostojen jakaminen, integraatiot)
• Aikataulutetut tehtävät ja taustapalvelut toimivat odotetusti
• Lokit ja valvontamerkit näkyä siellä, missä ops-tiimisi odottaa niitä

Lisää yksi askel, jonka tiimit usein ohittavat: varmista, miten käyttäjät todellisuudessa pääsevät sovellukseen, mukaan lukien sisäinen reititys, palomuurisäännöt ja kaikki ylävirran järjestelmät. Palvelin voi olla "terve", mutta käytännössä saavuttamaton.

Käynnistä siirtyminen ja viimeistele

Leikkaus on hallittu vaihto, ei uskon hyppy. Jäädytä muutokset, kun mahdollista, suorita liikenteen siirto suunnitellulla mekanismilla ja validoi sitten käyttämällä samaa tarkistuslistaa kuin testauksessa. Pidä palautusoikeus selkeänä, jotta päätökset ovat nopeita. Käsittele tätä toistettavana pelikirjana: mitä vähemmän improvisoit, sitä pienempi riski.

Siirtymisen toteutuksen perusteet:

• Vahvista muutoksen jäädytys ja viestintäsuunnitelma
• Käynnistä siirtymäinstanssi ja vaihda liikenne (DNS/LB/reititys)
• Suorita tarkistuslista uudelleen erityisesti tietojen eheyteen keskittyen.
• Käytä palautusliipaisimia tarvittaessa ja palauta liikenne siististi
• Viimeistele siirtyminen ja poista tai lopeta testiresurssit.

Välittömästi siirron jälkeen, tallenna mitä tuotannossa on muuttunut (uudet IP-osoitteet, uudet reitit, uudet turvallisuusryhmäsäännöt) ja dokumentoi se. Tämä on tieto, jota operatiivinen tiimi tarvitsee, kun jokin menee rikki viikkojen kuluttua.

Mikä yleensä menee rikki, ja mitä sinun pitäisi tehdä heti siirron jälkeen?

Verkkoliikenteen ulosmeno, DNS/AD-riippuvuudet ja "nosta ja siirrä ei ole tehty"

Useimmissa epäonnistumisissa on kyse riippuvuuksista. Replikointi katkeaa yleensä ulosmenon ja välityspalvelinrajoitusten vuoksi, kun taas sovelluksen käyttäytyminen katkeaa usein identiteetin, nimen ratkaisemisen ja sertifikaattien vuoksi. Vaikka siirtyminen onnistuu, uudelleen isännöinti on vain ensimmäinen virstanpylväs, ei lopullinen tila. Ilman toista vaihetta päädyt usein "pilvessä isännöityyn perintöön", joka maksaa enemmän ja on vaikeampi käyttää.

Yleisimmät katkaisupisteet:

• Ulkopuolinen HTTPS estetty tai muutettu välityspalvelimen toimesta TLS-tarkastus
• DNS-resoluution muutokset (split-horizon-ongelmat, puuttuvat resolver-säännöt)
• AD/LDAP-yhteyden katkokset VPC:stä
• Sisäiset PKI-ketjut puuttuvat tai eivät ole luotettuja uudessa ympäristössä
• Kovakoodatut päätepisteet ja vanhentuneet oletukset paikallisista verkko-osoitteista

Yksinkertainen lieventäminen on testata henkilöllisyys ja DNS aikaisin pilottijulkaisun yhteydessä. Jos nämä perusasiat toimivat, sovelluksen validoinnin muu osa muuttuu paljon ennustettavammaksi.

Leikkauksen jälkeinen vakauttaminen: turvallisuus, varmuuskopiot, valvonta, kustannus

Ensimmäiset 48 tuntia siirron jälkeen tulisi priorisoida vakautta ja hallintaa. Varmista, että työkuorma on havaittavissa, palautettavissa ja turvallisesti hallittavissa ennen kuin käytät aikaa syvempään optimointiin. Tämä on myös se, missä siirtyminen onnistuu pitkällä aikavälillä, koska hyvät toiminnot toisena päivänä estävät "siirsimme sen, mutta kukaan ei halua omistaa sitä" -tuloksia.

Välittömät leikkauksen jälkeiset toimenpiteet:

• Vahvista, että valvonta/hälytys on aktiivinen ja omistettu.
• Varmista, että varmuuskopiot ovat käytössä ja suorita palautuksen vahvistus.
• Tiukentaa turvallisuusryhmiä ja soveltaa vähimmäisoikeuksia IAM
• Standardoi päivitysmenettely ja hallintaoikeus (auditoitavat polut)
• Aloita oikean kokoisen ratkaisun etsiminen kerättyäsi todelliset käyttödatat.
• Pakota merkintä estämään "tuntematon omistaja" kustannusten poikkeama

Kun vakaus on todistettu, aikatauluta lyhyt optimointikatsaus jokaiselle siirretylle palvelimelle. Jopa kevyt tarkistus tallennustyypeistä, instanssiperhevalinnasta ja varatun kapasiteetin strategiasta voi merkittävästi vähentää kustannuksia.

Missä TSplus sopii, kun siirrät palvelimet AWS:ään?

Windows-työkuormien suorittamisen jälkeen AWS:ssä monet tiimit tarvitsevat edelleen yksinkertaisen tavan julkaista Windows-sovelluksia ja työpöytiä käyttäjille ilman raskaan VDI-pinon rakentamista. TSplus Etäyhteys toimittaa sovellusten julkaisemisen ja etätyöpöytäyhteyden Windows-palvelimille AWS:ssä, paikallisissa tai hybridikohteissa, yksinkertaisella hallinnalla ja ennakoitavalla lisensoinnilla, joka sopii pk-yrityksille ja keskikokoisille markkinoille.

Päätelmä

Paikallisen palvelimen siirtäminen AWS:ään on kaikkein onnistuneinta, kun se seuraa toistettavaa toimintasuunnitelmaa: valitse oikea siirtostrategia, validoi riippuvuudet, toista turvallisesti, testaa realistisesti ja siirry selkeillä palautusliipaisimilla. Kun tuotanto on vakaa, siirrä huomio toisen päivän toimintoihin: turvallisuuden vahvistaminen, varmuuskopioinnin validoiminen, valvonta ja oikean koon määrittäminen. Tämä muuttaa "siirron" luotettavaksi, kustannusvalvotuksi alustaksi.