Paano Maglipat ng On-Premises Server sa AWS (Simpleng Runbook)

Pakilala

Mas kaunti ang nabibigo na paglipat mula sa on-prem patungo sa AWS dahil sa compute at higit pa dahil sa mga kakulangan sa pagpaplano: hindi malinaw na mga layunin sa cutover, mga nakaligtaan na dependencies, at minadaling pagsubok. Pinapanatili ng gabay na ito na madali sundan ang proseso habang nananatiling operational. Itatakda mo kung ano ang hitsura ng tagumpay, ihahanda ang isang minimal na landing zone, magsasagawa ng mga pagsubok na paglulunsad ng AWS MGN, mag-cut over nang may kumpiyansa, at pagkatapos ay i-optimize ang workload pagkatapos itong maging live.

Ano ang Dapat Mong Isaalang-alang Bago Maglipat ng Anuman?

Alin ang estratehiya ng migrasyon na akma para sa server na ito (ang "7 Rs" ng AWS)?

Ang pinakamabilis na paraan upang mawalan ng oras ay ang ilipat ang maling bagay. Bago ka mag-install ng anumang ahente, magpasya kung aling estratehiya sa migrasyon ang nararapat sa server upang hindi mo ilipat ang isang bagay na dapat nang itigil o palitan. Sa praktis, maraming koponan ang nagsisimula sa rehosting para sa bilis, pagkatapos ay nag-o-optimize sa kalaunan kapag ang workload ay matatag na sa AWS.

Gayunpaman, ito ay gumagana lamang kapag ang server ay isang magandang "as-is" na kandidato at hindi lilikha ng mahal na teknikal na utang kaagad pagkatapos ng paglipat. Mga praktikal na desisyon na shortcut:

• Rehost: kumilos nang mabilis na may kaunting pagbabago kapag masikip ang oras.
• Replatforming: panatilihin ang app ngunit gumawa ng maliliit na pagsasaayos para sa akma sa AWS.
• Refactor: maglaan ng pagsisikap para sa mga pagkakaiba na mahalaga sa negosyo.
• Repurchase: palitan ng SaaS sa halip na ilipat ang server.
• Mag-retiro/Magpanatili: alisin ang hindi nagagamit na mga sistema o panatilihin ang mga limitadong workload sa on-prem.

Isang kapaki-pakinabang na panloob na checkpoint ay ang magtanong kung ang workload ay may "cloud future." Kung ang server ay kalaunan ay magiging bahagi ng mga pinamamahalaang serbisyo o nakakontrata, idokumento iyon ngayon at ituring ang rehosting bilang isang pansamantalang hakbang sa halip na isang permanenteng disenyo.

Ano ang RTO/RPO, Downtime Window, at mga Trigger ng Rollback?

Nagiging matagumpay ang mga cutover kapag ang tagumpay ay nasusukat. Tukuyin ang katanggap-tanggap na downtime at toleransya sa pagkawala ng data, pagkatapos ay isulat ang mga kondisyon na nag-uudyok sa rollback. Pinapanatili nitong layunin ang migrasyon at pinipigilan ang mga koponan na mag-improvise sa panahon ng cutover window. Nakakatulong din ito sa mga stakeholder ng negosyo na pumirma dahil makikita nila nang eksakto kung anong panganib ang tinatanggap.

Tukuyin at idokumento:

• RTO: pinakamataas na katanggap-tanggap na downtime.
• RPO: maximum na katanggap-tanggap na pagkawala ng data.
• Oras ng pagka-bangkarote: kapag pinapayagan kang lumipat ng trapiko ng produksyon.
• Rollback triggers: mga tiyak na kondisyon ng pagkabigo (auth outage, nabigong transaksyon, hindi pagkakatugma ng data).
• Paraan ng paglipat: DNS flip, load balancer switch, routing/firewall changes.

Upang mapanatiling makatotohanan ang plano ng rollback, tukuyin kung sino ang may-ari ng bawat aksyon sa panahon ng cutover. Halimbawa, isang tao ang may-ari ng mga pagbabago sa DNS, isang tao ang may-ari ng pagpapatunay ng aplikasyon, at isang tao ang may-ari ng "desisyon sa rollback" batay sa mga trigger sa itaas.

Ano ang Kailangan Mong Ihanda sa AWS at On-Prem Una?

Konektividad at mga batayan ng firewall para sa replication

Ang replication ay gumagana lamang kung ang source environment ay makakaabot sa AWS nang tuloy-tuloy. Ang pinaka-karaniwang hadlang ay ang mahigpit na egress controls, proxies, at TLS inspection na nakakasagabal sa outbound HTTPS traffic. I-validate ang koneksyon nang maaga at panatilihing matatag ang network path sa panahon ng paunang replication at mga pagsubok na paglulunsad. Sa maraming environment, ang replication ay hindi "naka-block" nang buo; sa halip, ang mga intermittent drops o packet inspection ay nagdudulot ng hindi matatag na pag-uugali na mahirap i-diagnose sa kalaunan.

Karaniwang mga pattern ng koneksyon:

• Pampublikong internet na paglabas (pinakasimpleng kapag pinapayagan)
• Site-to-site VPN (karaniwan para sa pribadong koneksyon)
• Direktang Kumonekta (mas mahuhulaan para sa mas malalaking kapaligiran)

Pre-flight checks:

• Ang Outbound HTTPS ay maaasahan mula sa source network.
• Nauunawaan at nasubok ang proxy na pag-uugali sa daloy ng migrasyon
• Inaprubahan ng mga koponan ng seguridad ang kinakailangang egress para sa bintana ng migrasyon.

Kung ang iyong kapaligiran ay mahigpit na nakasara, magdagdag ng maikling hakbang na “network proving” sa iyong plano ng alon: i-validate ang mga endpoint mula sa isang pilot server, pagkatapos ay ulitin ang eksaktong set ng patakaran para sa natitirang bahagi ng alon.

Minimal na checklist ng landing zone ng AWS

Hindi mo kailangan ng perpektong landing zone upang magsimula, ngunit kailangan mo ng isang pare-parehong target na hindi magbabago sa gitna ng alon. Panatilihing minimal ang build, ngunit sinadya, upang ang pagsubok ay sumasalamin sa kung ano ang magiging hitsura ng cutover. Maraming isyu sa migrasyon ang nagmumula sa "panandaliang" mga shortcut sa network na nagiging permanente dahil walang oras ang sinuman upang muling itayo ang mga ito pagkatapos ng paglulunsad.

Minimum landing zone elements:

• [A] - Isalin VPC at subnets kung saan ilulunsad ang mga instance (madalas na hiwalay na pagsubok laban sa produksyon)
• Mga grupo ng seguridad nakaayon sa tunay na daloy ng aplikasyon (iwasan ang "buksan ngayon, ayusin mamaya")
• IAM handa para sa mga operasyon ng migrasyon at access at tooling sa ikalawang araw
• Pangunahing tagging kaya ang pagmamay-ari at pagsubaybay sa gastos ay malinaw pagkatapos ng paglipat

Nakakatulong din ito na maagang magpasya kung paano makaka-access ang mga admin sa mga instance (bastion, VPN , SSM) at kung paano ibibigay ang outbound internet access (NAT gateway, proxy). Ang mga pagpipiliang ito ay nakakaapekto sa pag-patch, mga monitoring agent, at troubleshooting sa unang araw.

Checklist ng kahandaan ng source server

Ang isang malinis na migrasyon ay nakasalalay sa isang malinis na pinagmulan. Kumpirmahin na ang workload ay tugma sa pamamaraang pinili mo, pagkatapos ay tukuyin ang anumang bagay na nakasalalay sa mga lokal na palagay na magbabago sa AWS. Dito mo rin itinatampok ang mga "espesyal na kaso" na server na maaaring mangailangan ng ibang pagkakasunod-sunod. Halimbawa, ang isang file server na may mabigat na aktibidad sa pagsusulat ay maaaring mangailangan ng mas masikip na cutover window at mas mahigpit na pagpapatunay para sa mga bukas na file at share.

Pagsusuri ng kahandaan na pumipigil sa mga sorpresa:

• Kompatibilidad ng OS/workload sa pamamaraan ng migrasyon
• Sapat na disk at matatag na I/O para sa overhead ng replication
• Mga nakatalang dependencies: DNS , AD/LDAP , panloob PKI/sertipiko , mga database, mga bahagi
• Nakatagong pagkabrittle: hard-coded na IPs, legacy TLS, hindi karaniwang nakaiskedyul na mga gawain
• Mga espesyal na kaso na naitala nang maaga: mga domain controller, mga cluster, mga appliance, paglisensya ng dongle

Bago umalis sa hakbang na ito, kunin ang mga item na "dapat manatiling pareho" tulad ng hostname, mga kinakailangan sa IP address, o mga binding ng sertipiko, dahil ang mga ito ay direktang nakakaapekto sa iyong mga setting ng paglulunsad ng AWS at sa iyong pagkakasunod-sunod ng paglipat.

Paano Mo Ililipat ang isang Server sa AWS gamit ang AWS MGN?

I-set ang MGN at itakda ang mga default ng replication

I-setup ang AWS MGN sa Rehiyon kung saan tatakbo ang server, pagkatapos ay tukuyin ang mga default ng replication upang manatiling pare-pareho ang pagpapatupad ng wave. Ang isang matatag na template ay nagpapababa ng pagkakaiba-iba sa bawat server at ginagawang maulit ang pag-troubleshoot. Isipin ito bilang iyong pamantayang pamamaraan para sa replication, katulad ng isang gold image sa isang virtualized na kapaligiran.

Itakda ang mga default ng replication nang maaga:

• Target subnet strategy at paglalagay ng network
• Baseline ng grupo ng seguridad para sa mga inilunsad na instance
• Pag-uugali ng imbakan (volume mapping, enkripsyon inaasahan)
• Pagpapabagal ng replication upang protektahan ang trapiko ng produksyon

Kung alam mo na ang produksyon ay mangangailangan ng iba't ibang mga setting kaysa sa pagsubok, tukuyin ang mga pagkakaibang iyon nang tahasan. Sa ganitong paraan, ang mga pagsubok na paglulunsad ay mananatiling kinatawan nang hindi nalalantad ang mga network ng produksyon nang maaga.

I-install ang ahente at kumpletuhin ang paunang pagsasabay.

I-install ang replication agent sa source server at tiyaking matagumpay itong nakarehistro. Ang paunang sync ay kung saan ang kawalang-tatag ay nagkakahalaga sa iyo ng pinakamarami, kaya iwasan ang hindi kinakailangang mga pagbabago at masusing subaybayan ang kalusugan ng replication. Dito rin nakikinabang ang mga koponan sa pagdodokumento ng "kilalang mabuting" daloy ng pag-install upang hindi nila muling ayusin ang parehong mga isyu sa bawat alon.

Patnubay sa operasyon:

• Panatilihin ang server na matatag sa panahon ng paunang pag-uulit (iwasan ang mga reboot kung maaari)
• Subaybayan ang katayuan ng pag-uulit at agad na tugunan ang mga error.
• I-document ang paraan ng pag-install upang ang mga susunod na alon ay maging pare-pareho.

Sa panahon ng paunang pagsasabay, subaybayan hindi lamang ang migration console kundi pati na rin ang pagganap ng server. Ang replication overhead ay maaaring magbunyag ng mga bottleneck sa imbakan o mga error sa disk na dati nang nakatago sa on-prem na kapaligiran.

Maglunsad ng isang test instance at i-validate

Ang isang pagsubok na paglulunsad ay ginagawang ebidensya ang mga palagay. Ilunsad ang test instance, pagkatapos ay i-validate ang kalusugan ng aplikasyon mula simula hanggang wakas, hindi lamang ang tagumpay ng boot. Gumamit ng checklist upang ang pagsubok ay maulit sa iba't ibang server at alon. Kung ang mga end user ay kumokonekta sa pamamagitan ng TSplus Remote Access , isama ang isang access-path check sa validation. Mahalaga ang pagkakapare-pareho dahil pinapayagan ka nitong ihambing ang mga resulta sa pagitan ng mga workload at makita ang mga pattern, tulad ng mga isyu sa DNS resolution na nakakaapekto sa maraming server.

Minimum validation checklist:

• Nagtatapos ang boot at malinis na nagsisimula ang mga serbisyo
• Nakapasa ang mga application smoke test para sa mga pangunahing daloy ng trabaho
• Gumagana ang Authentication (AD/LDAP/local)
• Ang mga landas ng data ay gumagana (mga koneksyon sa DB, mga pagbabahagi ng file, mga integrasyon)
• Naka-iskedyul na mga trabaho at mga serbisyong pang-background ay tumatakbo ayon sa inaasahan
• Mga Log at mga senyales ng pagmamanman lumitaw kung saan inaasahan ng iyong ops team

Magdagdag ng isang hakbang na madalas na nalilipasan ng mga koponan: suriin kung paano talaga maa-access ng mga gumagamit ang aplikasyon, kabilang ang panloob na routing, mga patakaran ng firewall, at anumang upstream na sistema. Ang isang server ay maaaring "malusog" ngunit hindi maaabot sa praktika.

Ilunsad ang paglipat at tapusin

Ang Cutover ay isang kontroladong paglipat, hindi isang pagtalon ng pananampalataya. I-freeze ang mga pagbabago, kung maaari, isagawa ang paglipat ng trapiko gamit ang nakaplanong mekanismo, pagkatapos ay i-validate gamit ang parehong checklist tulad ng sa pagsusuri. Panatilihing malinaw ang pagmamay-ari ng rollback upang mabilis ang mga desisyon. Ituring ito bilang isang paulit-ulit na playbook: mas kaunti ang iyong improvisation, mas mababa ang panganib.

Mga pangunahing kinakailangan sa pagsasagawa ng cutover:

• Kumpirmahin ang pagbabago ng pagyeyelo at plano ng komunikasyon
• Ilunsad ang cutover instance at lumipat ng trapiko (DNS/LB/routing)
• Muling patakbuhin ang checklist ng pagpapatunay na may dagdag na pokus sa integridad ng data
• Mag-apply ng rollback triggers kung kinakailangan at ibalik ang trapiko nang maayos.
• Kumpletuhin ang paglipat at alisin o tapusin ang mga mapagkukunan ng pagsubok

Agad pagkatapos ng cutover, kunin ang mga pagbabagong naganap sa produksyon (mga bagong IP, mga bagong ruta, mga bagong patakaran sa grupo ng seguridad) at idokumento ito. Ito ang impormasyong kailangan ng ops team kapag may nasira ilang linggo mamaya.

Ano ang Karaniwang Nasira, at Ano ang Dapat Mong Gawin Kaagad Pagkatapos ng Paglipat?

Network egress, DNS/AD dependencies, at "hindi natapos ang lift-and-shift"

Karamihan sa mga pagkabigo ay mga pagkabigo sa dependency. Ang replication ay may posibilidad na masira sa egress at proxy constraints, habang ang pag-uugali ng application ay may posibilidad na masira sa pagkakakilanlan, resolusyon ng pangalan, at mga sertipiko. Kahit na magtagumpay ang cutover, ang rehosting ay unang milestone lamang, hindi ang huling estado. Nang walang pangalawang yugto, madalas kang nagtatapos sa "cloud-hosted legacy" na mas mahal at mas mahirap patakbuhin.

Pinakamadalas na breakpoints:

• Outbound HTTPS na naharang o binago ng proxy TLS inspeksyon
• Mga pagbabago sa resolusyon ng DNS (mga isyu sa split-horizon, nawawalang mga patakaran ng resolver)
• Mga puwang sa abot ng AD/LDAP mula sa VPC
• Nawawala o hindi pinagkakatiwalaang mga panloob na PKI chain sa bagong kapaligiran
• Hard-coded endpoints at mga legacy na palagay tungkol sa mga lokal na landas ng network

Isang simpleng hakbang ay subukan ang pagkakakilanlan at DNS nang maaga sa isang pilot launch. Kung gumagana ang mga batayang ito, ang natitirang pagpapatunay ng aplikasyon ay nagiging mas mahuhulaan.

Pagkatapos ng paglipat na pag-stabilize: seguridad, mga backup, pagmamanman, gastos

Ang unang 48 oras pagkatapos ng cutover ay dapat bigyang-priyoridad ang katatagan at kontrol. Tiyakin na ang workload ay nakikita, maibabalik, at ligtas na pinamamahalaan bago ka gumugol ng oras sa mas malalim na pag-optimize. Dito rin nagtatagumpay ang iyong migrasyon sa pangmatagalan, dahil ang magagandang operasyon sa ikalawang araw ay pumipigil sa mga resulta ng “inilipat namin ito, ngunit walang gustong magmay-ari nito.”

Agad na mga aksyon pagkatapos ng pagputol:

• Kumpirmahin na ang pagmamanman/pag-alerto ay aktibo at pagmamay-ari.
• Tiyakin na ang mga backup ay naka-enable at kumpletuhin ang isang pagpapatunay ng pagbawi
• Palakasin ang mga grupo ng seguridad at ilapat ang pinakamababang pribilehiyo IAM
• I-standardize ang pamamaraan ng pag-patch at administratibong pag-access (mga daan na maaaring suriin)
• Simulan ang tamang pagsasaayos pagkatapos mong mangolekta ng totoong datos ng paggamit.
• Ipatupad ang pag-tag upang maiwasan ang paglihis ng gastos mula sa "hindi kilalang may-ari"

Kapag napatunayan na ang katatagan, mag-iskedyul ng maikling pagsusuri ng optimisasyon para sa bawat na-migrate na server. Kahit ang isang magaan na pagsusuri sa mga uri ng imbakan, pagpili ng pamilya ng instance, at estratehiya sa nakalaang kapasidad ay maaaring makabuluhang magpababa ng gastos.

Saan Pumapasok ang TSplus Matapos Mong Ilipat ang mga Server sa AWS?

Matapos tumakbo ang mga workload ng Windows sa AWS, maraming koponan pa rin ang nangangailangan ng simpleng paraan upang ilathala ang mga aplikasyon at desktop ng Windows sa mga gumagamit nang hindi bumubuo ng mabigat na VDI stack. TSplus Remote Access nagbibigay ng pag-publish ng aplikasyon at remote desktop access para sa mga Windows server sa AWS, on-prem, o hybrid na kapaligiran, na may simpleng pamamahala at mahuhulaan na lisensya na akma para sa SMB at mid-market na operasyon.

Wakas

Ang paglipat ng isang on-premises na server sa AWS ay pinaka matagumpay kapag ito ay sumusunod sa isang paulit-ulit na runbook: pumili ng tamang estratehiya sa paglipat, suriin ang mga dependencies, kopyahin nang ligtas, subukan nang makatotohanan, at lumipat na may malinaw na rollback triggers. Kapag ang produksyon ay matatag na, ilipat ang pokus sa mga operasyon sa ikalawang araw: pagpapalakas ng seguridad, pagsuri ng backup, pagmamanman, at tamang sukat. Ito ay nagiging isang "paglipat" sa isang maaasahang, kontroladong gastos na platform.