TCP နဲ႕ UDP ဘာကြာ လည္း ?

TCP နဲ႕ UDP ဘာကြာ လည္း ? အလုပ္ထဲမွာ NLB အေၾကာင္းေျပာရင္းနဲ႕ ေျပာျဖစ္တယ္ ။ TCP က destination အတိအက်ကို လာျပီး ၊ UDP က broadcast ပုံစံသြားတယ္လို႕ ထင္ေနတယ့္ သူေတြ ေတြ႕လိုက္ရလို႕ပါ။ UDP မွာ Dest အမွန္က pick-up လုပ္၊ မဟုတ္တယ့္သူေတြ က drop တယ္လို႕ထင္ေနၾကတယ္။ Hub နဲ႕ Switch ကြာပံုနဲ႕ ေရာေနတယ္ထင္တယ္။ Tech engineer ေတြနဲ႕ေျပာတာမဟုတ္လို႕ (က်ေနာ္တို႕ PM နဲ႕ senior software eng တစ္ေယာက္ပါ)၊ non-technical ပံုစံပဲေျပာျဖစ္တယ္။

တစ္ခုက က်ေနာ္ severfault မွာဖတ္ဖူးတယ့္ CEO level explanation ။ ဆိုက်ပါေတာ့၊ CEO က စာရြက္သုံးရြက္ကို လုံးျပီး အမိႈက္ပုံးထဲကို ျပစ္ခ်င္တယ္။ စာရြက္သုံးရြက္က သူပို႕ခ်င္တယ့္ data ( packets) ပါ။ CEO ၾကီးက source ၊ အမိႈက္ပုံးက destination ေပါ့။ ဘယ္လိုျပစ္မလည္းဆိုတယ့္ manner က TCP / UDP ပါပဲ။ TCP လိုျပစ္ရင္ေတာ့ ပထမ တစ္ရြက္ျပစ္တယ္၊ ဝင္မဝင္ၾကည့္တယ္၊ ဝင္ရင္ ေနာက္တစ္ရြက္ထပ္ျပစ္တယ္။ ျပဳတ္က်သြားရင္ေတာ့ ( ထေကာက္ျပီးေတာ့) ေနာက္တစ္ခါထပ္ျပစ္တယ္။ အဓိကက စာရြက္သုံးရြက္လုံး အမိႈက္ပုံးထဲဝင္တာ ေသခ်ာဖို႕ စနစ္တက်ျပစ္တယ္ပဲ ဆိုပါေတာ့။ UDP ဆိုရင္ေတာ့ တစ္ ႏွစ္ သုံး ဆိုျပီး အမိႈက္ပုံးရွိမယ့္ဘက္ကို အကုန္ျပစ္လိုက္မယ္၊ ဝင္တာမဝင္တာ ဂ႐ုမစိုက္ဘူး ၊ မဝင္လည္းေနပါေစေပါ့။

CEO level က အရမ္း briefly ျဖစ္ေနတယ္။ ေနာက္ example တစ္ခုေျပာမယ္။ We should call it "Project manager level explanation" လို႕ေျပာေတာ့ PM က မ်က္ေထာင့္နီနဲ႕ၾကည့္တယ္။
က်ေနာ္တို႕ စာတစ္ေစာင္ ပို႕မယ္ဆိုပါေတာ့။ စာက Data ၊ က်ေနာ္က source ၊ က်ေနာ္ပို႕ခ်င္တယ့္ လိပ္စာက Destination ေပါ့။ ဘယ္လိုပို႕မလည္း ( transmission method ) ႏွစ္ခုေရြးစရာရွိမယ္ ။ DHL နဲ႕ ပံုမွန္ unregistered post mail ေပါ့။

DHL နဲ႕ပို႕တယ္ဆိုပါေတာ့ ၊
1. DHL က အိမ္ေရွ႕ကိုေရာက္ေအာင္လာမယ္ ( route)
2. အိမ္တခါးကို လာေခါက္မယ္ ( 3 way hand-shake)
3. ဒီ address မွာ ဒီစာကို လက္ခံႏိုင္ေၾကာင္း ေသခ်ာမွ
4. စာကိုေပးျပီးရင္လည္း လက္ခံရရွိေၾကာင္း လက္မွတ္ထိုးခိုင္းမယ္ ( Acknowledgement)
5. တကယ္လို႕ လက္ခံမယ့္ဘက္က လူမရွိရင္ပဲျဖစ္ျဖစ္ ၊ လက္ခံဖို႕အရမ္းအလုပ္ေတြရွုပ္ေနရင္ပဲျဖစ္ျဖစ္ ၊ ေနာက္တစ္ေခါက္ျပန္ပို႕မယ္ ( transmission control, windowing)
6. ဒီလိပ္စာက ဒီလူမရွိေတာ့တာမ်ိဳး၊ လိပ္စာမွားေနတာမ်ိဳးဆို sender ကိုျပန္ အေၾကာင္းၾကားမယ္။
Sender ဖက္က ပို႕လိုက္တာ ေရာက္မေရာက္ သိႏိုင္မယ္ ၊ လိုအပ္ရင္ ေနာက္တစ္ေခါက္ ၊ ေနာက္တစ္ေနရာ ပို႕ဖို႕လိုအပ္ရင္ လည္းသိရမွာေပါ့။

Unregisterd post mail ဆိုရင္ေတာ့
1. အိမ္ေအာက္က mailbox ကိုလာမယ္ ( route)
2. စာတိုက္ပုံးထဲ ထဲခဲ့မယ္
လက္ခံရမယ့္လူ အိမ္ေျပာင္းသြားလို႕ သူလက္ထဲမေရာက္လည္း တာဝန္မယူဖူး။ ေရာက္လားမေရာက္လားလည္း မသိႏိုင္ဘူး။
ဒီ example မွာ connection less နဲ႕ connection oriented ပံုစံကို ထဲ့မေျပာႏိုင္ေပမယ့္ ႏွစ္ခုလုံးက destination ကိုသိျပီး destination ကိုပဲေရာက္ေအာင္လာၾကတာပါပဲ။ Transmission control ပါတာနဲ႕ မပါတာပဲ အဓိကကြဲတယ္လို႕ ေျပာရင္ရပါတယ္။

Technical engineer ကိုဒါမ်ိဳးေျပာလို႕ မရႏိုင္ေပမယ့္ ၊ ဘာမွန္းမသိ စြတ္ေျပာတတ္တယ့္ သူေဌးေတြ ( PM ေတြေရာေပါ့) အတြက္ေတာ့ သူတို႕ညာဏ္နဲ႕ လိုက္မွီတယ့္ explanation ျဖစ္မယ္ထင္ပါတယ္ :D ။

စာမေရးတာၾကာျပီ ၊ ဘာမွ မလုပ္တာၾကာျပီ ။ တစ္ခုခုေသျခာျပန္လုပ္မယ္လို႕ စိတ္ကူးျပီး တျခား colleague တစ္ေရာက္စီကေန သူ download လုပ္ထားတယ့္ game အသစ္ေတြ 36 GB ဒီေန႕ copy လုပ္လိုက္ပါတယ္ ။

Divinity

Wired Equivalent Privacy ( WEP)

WEP နဲ႕ WEP cracking tutorial ကိုျပန္ရွင္းျပတာမ်ိဳး က်ေနာ္ Myanmar IT Resource Forums မွာ ေရးဖူးပါတယ္။ အဲတုန္းက Forum post ဆိုေတာ့ ေမးတာေျဖ၊ ျပန္ေျပာနဲ႕ article ပံုစံေတာ့မဟုတ္ဖူးေပါ့။ အဲတုန္းက ေရးခဲ့ဖူးတာကို က်ေနာ္ blog post ပံုစံ ျပန္ေရးၾကည့္ခ်င္တယ္။ Cracking tuto ေတာ့ ျပန္မရွင္းေတာ့ဖူး။

Wireless ရဲ့ အလုပ္လုပ္ပံုကစရေအာင္။ Wireless connection တစ္ခုခ်ိတ္ရင္ ပထမ Authenticate လုပ္ရတယ္။ ဒါကို associate လုပ္တယ္လို႕ေခၚပါတယ္။ Laptop တစ္ခုက Access point တစ္ခုကို ခ်ိတ္မယ္ဆိုရင္ ပထမဆုံး associate လုပ္ရပါတယ္။ ေနာက္ေတာ့ Association passed ျဖစ္သြားျပီဆိုရင္ data transmission စလုပ္လို႕ရပါျပီ။ ဒီ data ေတြက ေလထဲကသြားေနမွာဆိုေတာ့ Encrypt လုပ္ဖို႕လိုပါတယ္။ Wireless security method ေတြရဲ့ ကြာျခားမႈက ဘယ္လို encrypt လုပ္လည္း၊ ဘယ္လို data packet structure မ်ိဳးနဲ႕ ပို႕လည္းဆိုတာေတြပဲကြဲသြားတာပါ။ WEP key ေရာ WPA key ေရာ WPA2 key ေရာ လက္နဲ႕ ႐ိုက္ထဲ့ရတာၾကီးပဲ။ WEP အေၾကာင္းဆက္ရေအာင္။

WEP 64 bits key က Hexadecimal 10 လုံး၊ က်ေနာ္တို႕ wireless ခ်ိတ္ရင္ ႐ိုက္႐ိုက္ထဲ့ေနၾက။ Hex ကတစ္လုံးမွာ 4 bits ရွိတာ သင္ဖူးတယ္။ Hex 10 လုံးဆိုရင္ 40 bits ရွိရမွာ ၊ ဒါေပမယ့္ 64 bits key လို႕သုံးပါတယ္။ အဲဒီ 40 bits Hex 10 လုံးကိုေတာ့ password လို႕ပဲ သတ္မွတ္ပါတယ္။ ဒီ password က both ends မွာ သိဖို႕လိုပါတယ္ ။ ဆိုလိုတာကေတာ့ Wireless Access Point ဖက္မွာေရာ ၊ ခ်ိတ္မယ့္ client ( laptop ဆိုပါေတာ့) ဖက္မွာပါ ဒီ password ကို သိထားရမယ္။ ဒါကိုသုံးျပီး Associate လုပ္ရမွာကိုး။ ဒီ password က Hex 10 လုံး 40 bits၊ က်န္တယ့္ 24 bits ကိုေတာ့့ Initialization Vector(IV) လို႕ေခၚပါတယ့္ random generated binary string ပါ။ Password 40 bits + IV 24 bits = WEP Key 64 bits ျဖစ္သြားတယ္။ ဒါက WEP key အေၾကာင္း။ data transaction လုပ္ေတာ့ ဒီ key ကို ဘယ္ေနရာမွာသုံးလည္းဆိုေတာ့ ..

( နည္းနည္း ရွုပ္ရေအာင္ ။) WEP မွာ hash / encryption အတြက္ RC4 Algorithm ကိုသုံးပါတယ္။ ခုနက ရထားတယ့္ 64 bits key ကို RC4 ကိုသုံးျပီး encrypt လုပ္လိုက္ပါတယ္။ အဲဒီကေနရလာတယ့္ hash ကိုသုံးျပီး ပို႕ခ်င္တယ့္ data ကို Eclusive Or (XOR) လုပ္လိုက္ပါတယ္။ DATA ကို XOR လုပ္လိုက္လို႕ ရလာတယ့္ Cipher text ကိုမွ ခုနက 24 bits IV နဲ႕ တြဲျပီး transmit လုပ္ပါတယ္ ။ လက္ခံရရွိတယ့္ ဘက္မွာက 40 bits password ကသိေနျပီးသားေလ။ အဲေတာ့ သိျပီးသား Password ရယ္၊ ပို႕တယ့္ ထဲမွာပါတယ့္ IV ရယ္ေပါင္းလိုက္၊ ျပီးေတာ့ RC4 နဲ႕ Encrypt ျပန္လုပ္၊ ရလာတယ့္ hash နဲ႕ ခုနက လက္ခံရရွိတယ့္ Cipher text ကို XOR ျပန္လုပ္၊ ဒါဆို data ကို decipher text အေနနဲ႕ ျပန္ျမင္ရျပီ။ ေတာ္ေတာ္ ရွုပ္သြားတယ္။ ငယ္မူျပန္ျပီး ABCD ေတြနဲ႕ စဥ္းစားၾကည့္ရေအာင္။

40 bits Password က A လို႕ဆိုပါေတာ့။ WEP အတြက္ randomly generate လုပ္လိုက္တယ့္ 24 bits IV ကို B လို႕ ဆိုပါေတာ့။ ဒါဆို 64 bits WEP key က AB ျဖစ္သြားျပီ။ ဒီ AB ကို RC4 ကိုသုံးျပီး hash လုပ္လိုက္ေတာ့ C ဆိုတယ့္ hash တစ္ခုရလာပါတယ္ ။

ပို႕မယ့္ Data က 'X' လို႕ထားပါေတာ့။ ( Data လို႕ဆိုတယ့္ေနရာမွာ Integrity check အတြက္ checksum ပါ ပါပါတယ္။) ခုနက ရထားတယ့္ hash 'C' နဲ႕ Data 'X' ကို XOR လုပ္လိုက္ပါတယ္။ Result ကေတာ့ Cipher text တစ္ခုျဖစ္တယ့္ 'Y' ကိုရလာပါတယ္ ။ ဒါဆိုပို႕လို႕ရျပီ။ Cipher text ျဖစ္ေနတယ့္ Y ရယ္၊ IV ျဖစ္တယ့္ B ရယ္ကို data packet ထဲမွာ ထဲ့ပို႕လိုက္ပါတယ္။

လက္ခံရရွိတယ့္ ဘက္ကေရာ။ သူက Cipher text 'Y' ရယ္၊ IV 'B' ရယ္ ရတယ္။ Data က cipher text ဆိုေတာ့ ဖတ္လို႕မရေသးဘူး။ Decrypt ျပန္လုပ္ရအုန္းမယ္။ သူ႕မွာ Password 'A' ကရွိေနျပီးသား၊ သိျပီးသားပါ။ လက္ခံရရွိတယ့္ packet ထဲမွာ IV ျဖစ္တယ့္ 'B' က plain text အျဖစ္ပါလာတယ္။ အဲေတာ့ ဒီႏွစ္ခုေပါင္း AB ကိုရျပီ။ AB ကို သူ႕ဘက္မွာလည္း RC4 encrypt လုပ္လိုက္ေတာ့ hash ျဖစ္တယ့္ 'C' ကိုရပါျပီ။ လက္ခံရရွိထားတယ့္ Cipher text 'Y' ကို hash 'C' နဲ႕ျပန္ျပီးေတာ့ XOR ျပန္လုပ္လိုက္ရင္ Data ျဖစ္တယ့္ 'X' ကို plain text အျဖစ္ျပန္ရပါတယ္။ ( XOR က symmetric ပါ။ C နဲ႕ X ကို xor ရင္ Y ကိုရသလို၊ C နဲ႕ Y ကို xor ျပန္လုပ္ရင္ X ကိုျပန္ရပါတယ္။ အျပန္အလွန္ရတယ္ေပါ့။ ) ဒီပံုက KSA နဲ႕ PRGA ဆိုတာ RC4 ရဲ့ အဆင့္ေတြပါ။ (Disclaimer: I grubbed this image from Google image search)



WEP ရဲ့ အားနည္းခ်က္က အဓိကျဖစ္တယ့္ IV က 24 bits ထဲျဖစ္ေနျပီးေတာ့၊ transmission မွာ plain text အျဖစ္ပို႕ဖို႕ လိုအပ္ေနတာပါပဲ။ အရင္ကေတာ့ WEP မွာ IV ကို ဘယ္လို generate လုပ္မလည္းဆိုတာ ေပၚမွာ ၊ ကြဲျပားပါေသးတယ္။ တခ်ိဳ႕ hardware vendor ေတြက IV ကို အစီအစဥ္တၾက generate လုပ္တယ္။ 00 .. 01 .. 10 .. 11 အဲလိုေပါ့။ ဒါက မွန္းရတာလြယ္လို႕ ေနာက္ေတာ့ pattern တစ္ခုနဲ႕ generate လုပ္ၾကတယ္။ ဒါလည္း pattern ကို ရွာရတာ မခက္ျပန္ဖူး။ ေနာက္ေတာ့ လုံးဝ စိတ္ကူးတဲ့သလို randomly generate လုပ္တာကို သုံးၾကတယ္။ ဒါေပမယ့္ ျပသနာကရွိေနပါေသးတယ္။ 24 bits မို႕ range ကနည္းပါတယ္ 16 သန္းေက်ာ္ေက်ာ္ပဲရွိပါတယ္။ အဲေတာ့ random pick တယ့္ အခါမွာ အခ်ိန္အတိုင္းအတာ တစ္ခုမွာ ျပန္ထပ္တတ္ပါတယ္။ အမ်ားအားျဖင့္ 10000 နဲ႕ 20000 ၾကားမွာ တစ္ခါ ထပ္ပါတယ္။

WEP ကို crack တယ့္ သူက အမ်ားအားျဖင့္ ARP request တစ္ခုကိုေစာင့္ျပီး အၾကိမ္ၾကိမ္ ဒီ request ကိုပဲ reply လုပ္ပါတယ္။ ဆိုလိုတာက data ကေျပာင္းလည္းမသြားဘူး၊ Wireless AP ဘက္က respond မွာသာ IV က random ျဖစ္ေနလို႕ reply ျပန္လာတယ့္ cipher text 'Y' က အမ်ိဳးမ်ိဳးျဖစ္ေနမယ္။ တကယ့္ data 'X" ကမေျပာင္းလည္းဘူးဆိုတာကို သိေနတယ့္ knowledge ကို အေျခခံျပီး IV ျပန္ထပ္သြားတယ့္ အခ်ိန္မွာ collect လုပ္ထားတယ့္ IV ေတြကေန WEP password ကိုျပန္တြက္ယူလို႕ရပါတယ္။ ဒါကေတာ့ algorithm ကို study လုပ္ဖို႕လိုပါမယ္၊ သိခ်င္ရင္ေျပာတာပါ။


Hacker ၾကီးေတြအတြက္ေရးတယ့္ စာမဟုတ္လို႕ Technical ပိုင္းေတြကို တတ္ႏိုင္သေလာက္ရွင္းထားပါတယ္။ WLAN နဲ႕ WAN ဘာကြာမွန္းမသိတယ့္ သူမ်ားအတြက္လည္းမဟုတ္လို႕ ခေရေစ့တြင္းက် မေရးႏိုင္တာကိုလည္း ခြင့္လႊတ္ပါ။ :D

With regards,
Divinity

Server Clustering ဆိုတာ . . . (2)

Clustering မွာ ဘယ္လိုအဆင့္ေတြရွိလည္း ?
ေခါင္းစဥ္က သိပ္မကြဲပါဘူး။ ျမန္မာစာ ပညာရွိမဟုတ္ေတာ့ စကားလုံးေရြးရတာ တခါတေလ မလြယ္ဘူး။ Clustering မွာ ဘယ္လို level အလိုက္ရွိလည္းလို႕ေျပာရင္ ပိုေကာင္းမယ္။
1. Network Level Clustering
2. Service Level Clustering
3. Application Level Clustering ဆိုျပီး ေယဘူရအားျဖင့္ သုံးခုရွိပါတယ္။ Failover ပံုစံအလုပ္လုပ္မလား၊ NLB အလုပ္လုပ္မလားဆိုတာက ဘယ္လို Setup လုပ္လည္းဆိုတာေပၚမွာ မူတည္ပါတယ္။ ဘယ္လို Level clustering မွာမဆို ႏွစ္မ်ိဳးလုံး ( တစ္မ်ိဳးမဟုတ္ တစ္မ်ိဳး) setup လုပ္ဖို႕ျဖစ္ႏိုင္ပါတယ္။

Network Level Clustering ( Vs Service Level Clustering)
သူကရွင္းပါတယ္။ တကယ္လို႕ Cluster ထဲမွာ Server 5 လုံးရွိတယ္ဆိုပါေတာ့။ ဒီ Server ငါးလုံးက အခ်င္းခ်င္း Network reachability ကို စစ္ေနပါတယ္။ Engineer က configure လုပ္ထားသလို 5 seconds ဆိုလည္း 5 seconds တိုင္းမွာ၊ 5 minutes ဆိုလည္း 5 minutes တိုင္းမွာ စစ္ေနပါတယ္။ Network reachability ဆိုတာကေတာ့ က်ေနာ္တို႕ ping ၾကည့္သလိုေပါ့။ ကိုယ္သုံးတယ့္ clustering technology ေပၚမွာမူတည္ျပီး ဘယ္လိုစစ္ေနလည္းဆိုတာေတာ့ ကြာပါလိမ့္မယ္။ တကယ္လို႕ unreachable ျဖစ္သြားျပီဆိုရင္ အဲ Server down သြားျပီလို႕ ယူဆျပီး Server ကို Cluster ထဲကေနဖယ္လိုက္ပါတယ္။ ဒီ Clustering ရဲ့ အားနည္းခ်က္ကေတာ့ Server ၾကီးက မ down ဘူး၊ Server ေပၚက Service ကပဲ down ေနရင္ သူမသိပါဘူး။ သူက Network အရ ping ၾကည့္လို႕ ဒီ Server alive ရွိမရွိ စစ္တာမ်ိဳးပဲစစ္ျပီး ဆုံးျဖတ္လို႕ Network Level Clustering လို႕ေျပာတာပါ။

ဥပမာ စဥ္းစားၾကည့္ရေအာင္။ Windows Server 2003 မွာ Windows NLB Manager ဆိုတာ ပါပါတယ္။ သူက Network Level Clustering ပါ။ NLB ပံုစံ Clustering ပါ။ Server သုံးလုံးကို IIS web server run ျပီး Cluster လုပ္လိုက္ၾကတယ္ဆိုပါေတာ့ ။ User က Access လုပ္ရင္ Server သုံးလုံး တစ္လွည့္စီ respond လုပ္ေနမွာေပါ့။ တကယ္လို႕ Svr 1 က hang သြားတယ္ ဆိုပါေတာ့ ၊ ဒါမွမဟုတ္လည္း network ၾကိဳးလြတ္သြားတာပဲျဖစ္ျဖစ္၊ ဒါမ်ိဳးဆိုရင္ Svr 1 down သြားတာကို က်န္တယ့္ Sever ႏွစ္လုံးက သိပါတယ္။ လာသမွ် user ကို Svr 2 နဲ႕ 3 ကပဲ မွ်ျပီး respond လုပ္ပါလိမ့္မယ္။

ဒါေပမယ့္ တကယ္လို႕ Server 1 ၾကီးက ဘာမွမျဖစ္ဖူး ၊ IIS ကပဲ crash ျဖစ္ျပီး stop ျဖစ္သြားတယ္။ ဒီလို scenario မွာ က်န္တယ့္ Server ႏွစ္လုံးက မသိပါဘူး။ Network aspect အားျဖင့္ Server 1 က alive ရွိေနပါတယ္။ IIS Service down သြားတာ ၊ ဒီ Network Level Cluster မွာ ဒါကို မသိပါဘူး။ ဒါဆို ဘာျဖစ္မလည္း ? Cluster က Svr1 down ေနတာကို မသိတယ့္အတြက္ request 3 ခါမွာ တစ္ခါကို ထုံးစံအတိုင္း Svr1 ဆီကို ပို႕ေနပါလိမ့္မယ္။ ဒါေပမယ့္ IIS ၾကီးက down ေနေတာ့ သုံးခါမွာ တစ္ခါ error ျပေနမွာေပါ့။ Reload လုပ္လိုက္ရင္ ျပန္ေကာင္းသြားျပန္ေရာ။

ဒါဆိုဘယ္လိုလုပ္မလည္း ? Service Level ကိုပါ monitor လုပ္ႏိုင္ဖို႕လိုပါတယ္။ Windows ရဲ့ built-in ေတြမွာေတာ့ မေတြ႕မိပါဘူး။ က်ေနာ္မသိတာလည္းျဖစ္ႏိုင္ပါတယ္။ Linux မွာေတာ့ heartbeat version 2 တို႕ LDirector တို႕ေတာ့ Opensource ေတြရွိပါတယ္။ သူတို႕က Service port ကိုပဲျဖစ္ျဖစ္ Service ကိုတစ္နည္းနည္းနဲ႕ စစ္ေပးျပီး Service down ရင္လည္း Server down တယ္လို႕ သတ္မွတ္ျပီး Cluster ထဲကေန isolate လုပ္ေပးလိုက္ပါတယ္။

API ေတြနဲ႕ခ်ိတ္ဆက္ျပီး Application တစ္ခု Process တစ္ခုကို Server ေတြအမ်ားၾကီးေပၚမွာ ခြဲေဝျပီး အလုပ္လုပ္တယ့္ Application Level Clustering ကေတာ့ က်ေနာ္ ေသခ်ာမရွင္းႏိုင္တယ့္ အေၾကာင္းအရာမို႕ ေက်ာ္လိုက္ပါရေစ။

Divinity

Server Clustering ဆိုတာ . . . (1)

Clustering ဆိုတာ ဘာလည္း ?
ႏွစ္လုံး သို႕မဟုတ္ ႏွစ္လုံးထက္ပိုတယ့္ Server ေတြ၊ ဒါမွမဟုတ္လည္း Computer ေတြဟာ Application တစ္ခု ( တနည္းအားျဖင့္ အလုပ္တစ္ခု) ကို အတူတကြ အလုပ္လုပ္ၾက ၊ serve လုပ္ၾကတာျဖစ္ပါတယ္။ website ေတြ လူသုံးအလြန္မ်ားလာတာမ်ိဳး ၊ database ေတြ query access အလြန္မ်ားလာတာမ်ိဳးၾကရင္ Server တစ္လုံးထဲနဲ႕ ျပန္ျပီး respond လုပ္ဖို႕ မႏိုင္ေတာ့ပါဘူး။ Server ေတြခြဲျပီး Cluster လုပ္လိုက္ခ်င္းအားျဖင့္ ပိုေကာင္းတယ့္ respond time ကိုလည္းရႏိုင္သလို ၊ Server တစ္လုံးလုံးမွာ network error ပဲျဖစ္ျဖစ္ hardware failure ပဲျဖစ္ျဖစ္ ( HDD ပ်က္သြားတာမ်ိဳး) တစ္ခုခုျဖစ္ရင္ Site တစ္ခုလုံး ၊ Database တစ္ခုလုံး ရပ္သြားျခင္းမွလည္း ကာကြယ္ႏိုင္ပါတယ္။

Clustering လုပ္တဲ့ ပံုစံ အမ်ိဳးမ်ိဳးရွိပါတယ္။ Cluster တစ္ခုမတည္ေဆာက္ခင္မွာ ကိုယ့္ရဲ့ လိုအပ္ခ်က္ ေပၚမွာ မူတည္ျပီး ဘယ္လို Clustering မ်ိဳးလုပ္မလဲဆိုတာ ဆုံးျဖတ္ရပါတယ္။ ေယဘူရ အားျဖစ္ေတာ့ Clustering ပံုစံ ႏွစ္မ်ိဳးရွိပါတယ္။

Failover cluster
Server ႏွစ္လုံးရွိေနမယ္၊ တစ္လုံးက down သြားရင္ ေနာက္တစ္လုံးက ခ်က္ခ်င္း ပထမ server ေနရာကိုယူျပီး respond ဆက္လုပ္ေနတာမ်ိဳးပါ။ User ေတြဘက္ကၾကည့္ရင္ Server တစ္လုံး down သြားတာ သိလိုက္မွာမဟုတ္ပါဘူး။ Active - Passive setup လို႕လည္း ေခၚပါတယ္။

ဥပမာ WebSvr1 နဲ႕ WebSvr2 ဆိုၾကပါဆို႕။Server ႏွစ္လုံးစလုံးက www.example.org ဆိုတဲ့ Website ကို host လုပ္ထားတယ္ ဆိုပါေတာ့။ ပံုမွန္အားျဖင့္ WebSvr1 ကပဲ respond လုပ္ပါတယ္။ User 1 က www.example.org လို႕ surf လုပ္ရင္ WebSvr1 ကပဲ respond ျပန္သလို၊ User 2 က www.example.org လို႕ surf ရင္လည္း WebSvr1 ကပဲ respond လုပ္ပါတယ္။ WevSvr1 အေၾကာင္းတစ္ခုခုေၾကာင့္ down သြားရင္ေတာ့ WevSvr2 က အစားထိုးဝင္ေရာက္ျပီး User 1 နဲ႕ User 2 ကို respond လုပ္ပါတယ္။ User 1 နဲ႕ User 2 အေနနဲ႕ Svr1 down သြားေၾကာင္း သိလိုက္မွာ မဟုတ္ပါဘူး။ ဒါ Failover cluster ပါ။

Load balance cluster
Active - Active setup လို႕လည္း သုံးေလ့ရွိပါတယ္။ Server ႏွစ္လုံး သို႕မဟုတ္ ႏွစ္လုံးထက္ပိုတယ့္ server ေတြက အလုပ္တစ္ခုကို မွ်ေဝလုပ္ၾကတာမ်ိဳးပါ။ ( Grid computing ၊ Server System Image တို႕ကို hardware level clustering အျဖစ္ေျပာၾကေလ့ရွိပါတယ္။ Server clustering technology တစ္ခုခ်င္းကို ေနာက္မွ အခြင့္သင့္ရင္ အေသးစိတ္ေရးပါအုန္းမယ္။ )

အခုေတာ့ ျမင္သာေအာင္ Network Load Balancing Cluster ကို ဥပမာေပးပါရေစ။၊ အေပၚက ဥပမာအတိုင္း Website တစ္ခုကို web server ႏွစ္လုံးက round-robin network load balanced ပံုစံနဲ႕ ဥပမာ ေျပာရရင္၊ Web Server ႏွစ္လုံးရွိမယ္ WebSvr1 နဲ႕ WebSvr2။ Server ႏွစ္လုံးစလုံးက www.example.org ဆိုတဲ့ Website ကို host လုပ္ထားတယ္ ဆိုပါေတာ့။ User 1 က www.example.org လို႕ surf လုပ္လိုက္ရင္ WebSvr1 က respond လုပ္ပါမယ္။ User 2 က surf လုပ္ရင္ WebSvr2 က respond လုပ္ပါမယ္။ တကယ္လို႕ User 3 ထပ္ေရာက္လာရင္ WebSvr1 က respond လုပ္ပါလိမ့္မယ္။ Server loading ကို balance လုပ္ယူလိုက္တာပါ။ User 4 ထပ္ေရာက္လာရင္ Svr2 က respond လုပ္ပါလိမ့္မယ္။ တကယ္လို႕ Svr1 ကသာ down သြားရင္ User ေလးေယာက္လုံးကို Svr2 က ဆက္ျပီး respond လုပ္ပါလိမ့္မယ္။ Load balanced လုပ္ထားရာကေန ၊ တစ္လုံးျပဳတ္သြားေတာ့ ပိုေတာ့ ေႏွးသြားေကာင္း ေႏွးသြားႏိုင္ပါတယ္။

Failover နဲ႕ NLB ဘာကြာလဲ
Srv 1 down သြားရင္ Srv 2 က အလုပ္လုပ္ေပးတာ၊ ဒါဆို သိပ္မကြာဘူးလို႕ ထင္ႏိုင္ပါတယ္။ ေရာေနႏိုင္လို႕ ျပန္ရွင္းပါမယ္။ Failover မွာတုန္းက Server ႏွစ္လုံးက Active-Passive ပါ။ Active အလုံးက ေကာင္းေကာင္းအလုပ္လုပ္ေန ေသးသမွ် Passive အလုံးက standby အေနအထားမွာပဲေနပါတယ္။ အလုပ္ဝင္မလုပ္ပါဘူး။ သူ႕ဟာသူ မႏိုင္မနင္းျဖစ္လည္း ဂ႐ုမစိုက္ပါဘူး။ သူ down မွ ငါ role တက္မွာဆိုတာမ်ိဳးစိတ္ထားနဲ႕ကို လစ္လွ်ဴ႐ႉထားပါတယ္။ NLB မွာကေတာ့ Active-Active ပါ။ ရွိသမွ် Server အားလုံးက load ကို ခြဲယူထားတာပါ။ အေပၚက Scenario မွာ server ႏွစ္လုံးဆိုေပမယ့္ Server သုံးလုံး အေနနဲ႕ စဥ္းစားရင္ ပိုရွင္းမယ္ထင္ပါတယ္။ User ေျခာက္ေယာက္ကို Server သုံးလုံးက ႏွစ္ေယာက္စီခြဲျပီး respond လုပ္ေနရာကေန၊ Srv 1 down သြားရင္ Srv 2 ေန႕ Srv 3 က သုံးေယာက္ဆီ ခြဲယူျပီး respond လုပ္ေပးပါလိမ့္မယ္။ Srv 1 မ down ခင္ကလည္း သူတို႕ အလုပ္လုပ္ေနပါတယ္။ Srv 1 down သြားေတာ့ သူတို႕ပိုအလုပ္ရွုပ္သြားတယ္။

အခုေနာက္ပိုင္းမွာ failover စစ္စစ္ကို သုံးတာ ရွားပါတယ္။ NLB server ငါးလုံးအတြက္ Srv တစ္လုံးကို standby အေနနဲ႕ ထားေပးထားတာမ်ိဳးပဲရွိပါေတာ့တယ္။ Server တစ္လုံးအတြက္ ေနာက္တစ္လုံး standby ထားေပးထားတာမ်ိဳး မလုပ္ၾကေတာ့ပါဘူး။ ကုန္က်စရိတ္အရေရာ ၊ မီတာအလကား ကုန္ေနတာမ်ိဳးလည္း မျဖစ္ေအာင္ပါ။


Server ေတြကို cluster လုပ္ျပီး သုံးရင္ ဘာေတြပိုေကာင္းမလည္း ?
1 . High Availability
ႏွစ္လုံးထက္ပိုတယ့္ Server ေတြကို အတူတကြ အလုပ္လုပ္ေစတာမို႕လို႕ Failover မွာပဲျဖစ္ျဖစ္ NLB မွာပဲျဖစ္ျဖစ္ Server တစ္လုံး down သြားရုံနဲ႕ operational state ရပ္မသြားပါဘူး။ ဆက္ျပီး အလုပ္လုပ္ေနႏိုင္ေသးတယ့္ အတြက္ Availability အသုံးျပဳႏိုင္စြမ္း ပိုျမင့္ေစပါတယ္။ ဒါဟာ User ေတြရဲ့ စိတ္ေၾကနပ္မႈအတြက္ အေရးပါပါတယ္။
2. Better Performance
Failover cluster မွာေတာ့ ဒီအခ်က္ဟာ သိပ္အၾကဳံးမဝင္ပါဘူး။ NLB cluster မွာေတာ့ Request 200 ကို Server တစ္လုံးထဲက reply လုပ္တာထက္၊ Server ႏွစ္လုံးက reply လုပ္တာမို႕ ပိုျမန္ျမန္ဆန္ဆန္ respond လုပ္ႏိုင္တာ ေတြ႕ရပါလိမ့္မယ္။
( Note: CPU 3.0 MHz နဲ႕ Memory 4GB server ႏွစ္လုံးကို cluster လုပ္တာနဲ႕ CPU 3.0 MHz Dual Processor နဲ႕ Memory 8GB server တစ္လုံး performance ခ်င္းယွဥ္ရင္ Cluster ကသာပါလိမ့္မယ္။ ကိန္း ဂဏန္းအရ အတူတူေလာက္ရွိေပမယ့္ motherboard က bus speed တို႕၊ Network traffic တို႕ ထဲ့တြက္ရပါလိမ့္မယ္။ Critical application ဆိုရင္ High-Availablity(HA) ကိုလည္း အေရးပါတယ့္ factor အေနနဲ႕ ထဲ့တြက္ရပါတယ္။ )
3. Better Scalability
User ေတြအရမ္းမ်ားလာမွ တစ္လုံးထဲကေန ပိုျပီး powerful ျဖစ္တယ့္ Server ကိုေရႊ႕ရရင္ မလြယ္ပါဘူး။ Clustered environment မွာေတာ့ cluster ကို တိုးခ်ဲ႕ရတာ ပိုလြယ္ပါတယ္။ Cluster ထဲကို Server ေတြတိုးျပီး ၊ load ကိုျပန္ထိန္းဖို႕က ပိုျပီး အဆင္ေျပ လြယ္ကူပါတယ္။

Clustering မွာ ဒီႏွစ္ခုကိုပဲေျပာေနတယ္ ထင္အုန္းမယ္။ ဒီ concept ႏွစ္ခုအတြက္ technology အမ်ိဳးမ်ိဳး ကြဲျပီးျဖစ္လာတာမို႕၊ ဒီႏွစ္ခုကို အရင္ေျပာခ်င္လို႕ပါ။ ဒါေပမယ့္ ဆက္ေျပာခ်င္တယ့္ အေၾကာင္းအရာေတြက စာၾကီးပဲဖတ္ဖို႕ထက္ ပံုေလးေတြနဲ႕မွပိုအဆင္ေျပမယ္ထင္တယ္။ ပံုေလးေတြဆြဲျပီးမွ ေနာက္ post တစ္ခုဆက္ေရးေတာ့မယ္ဗ်ာ။

Divinity