NovaX

22/08/2026

🎶တိတ်ဆိတ်ခြင်းနဲ့ နှလုံးသားတွေကို ကိုင်လှုပ်ခဲ့သူ 🎻🎹🥁🎺🎷🎶🎵

ဂီတသမိုင်းမှာ အလှပဆုံးနဲ့ အမှောင်မိုက်ဆုံး အချိန်တွေကို တပြိုင်နက်တည်း ကြုံတွေခဲ့ရတဲ့ ဂီတနတ်ဘုရားတစ်ပါး ရှိခဲ့ဖူးပါတယ်။ Ludwig van Beethoven ဆိုသူပါပဲ။

Beethoven ရဲ့ ငယ်ဘဝဟာ အများထင်သလိုလှပမနေခဲ့ပါဘူး။ အရက်စွဲနေတဲ့ ဖခင်ဖြစ်သူဟာ သူ့ကို Mozart တို့လို ဂီတပါရမီရှင် ကလေးငယ်တစ်ယောက် ဖြစ်စေချင်လွန်းလို့ Piano နဲ့ Violin သင်ခန်းစာတွေကို မနက်မိုးလင်းကနေ ညနက်သန်းခေါင်အထိ မနားတမ်း လေ့ကျင့်ခိုင်းခဲ့ပါတယ်။နေ့စဉ် ဆဲဆိုခံရ ရိုက်နှက်ခံခဲ့ရတဲ့အတွက် ဗီသိုဗင်ဟာ မျက်ရည်စက်လက်နဲ့သာ တူရိယာတွေကို တီးခတ်ခဲ့ရတာပါ။

ဒီလို ဖခင်ရဲ့ ဖိနှိပ်ချုပ်ချယ်မှုတွေ စက်ဆုပ်စရာတွေဒဏ်ရာတွေနဲ့ ငယ်ဘဝကို ..ဂီတနဲ့ ကျော်ဖြတ်ခဲ့ရတာကြောင့် သူ့ အသက် ၃၀ ဝန်းကျင်မှာတော့ ဂီတပညာရှင်တစ်ယောက်အတွက် ဂီတသမားတယောက်ရဲ့ အဆိုးရွားဆုံး ဆိုရမယ့် နားမကြားရတော့ခြင်း (Deafness) နဲ့ ရင်ဆိုင်ခဲ့ရပါတယ်။ တကယ်တော့ဂီတ သမားတယောက်အတွက် အကြားအာရုံ ဆုံးရှုံးရတာဟာ သေသွားတာထက် တောင် ပိုခက်ခဲပါတယ်။

Music သင်တဲ့ အခါ မြင်ရတဲ့ Notes တွေကို ပါးစပ်က ရွတ်ရပါတယ်။ ဒါကို နားက ကြား
င်း ဦးနှောက်က Melody သံစဉ်အဖြစ် လိုက်မှတ်ပါတယ်။ ပြီးတော့မှ fingers တွေက Muscle Memory အနေနဲ့ တူရီယာအပေါ်မှာ သဘာဝကျကျ တီးခတ်ပါတယ်။

💻 Technical အသစ်တခုကို ကျွန်တော်စလေ့လာတဲ့ အခါ မှာလည်း (ပါးစပ်ကအသံထွက်ရွတ်ပြီး) လက်ကချရေးတဲ့ Somatosensory Cortex ပုံစံနည်းလမ်းကိုသုံးပြီး Music ကိုလေ့လာသလိုမျိုး Learning လုပ်ပါတယ်။ဒါက ကျွန်တော့်အတွက် ပို အလုပ်ဖြစ်စေလို့ပါ။

နားမကြားရတော့တဲ့အချိန်မှာ လူအများက ဗီသိုဗင်တယောက် သူ့ဂီတလမ်းကြောင်း ပြီးဆုံးသွားပြီလို့ ထင်ခဲ့ကြပါတယ်. ဒါပေမဲ့ Beethoven ကတော့ ဇွဲမလျှော့ခဲ့ပါဘူး။

သူ့ရဲ့ အမိုက်မှောင်ဆုံးအချိန်တွေမှာပဲ ဂီတသမိုင်းမှာ အကြီးကျယ်ဆုံးလို့ တင်စားကြတဲ့ Symphony 9 ကို ဖန်တီးခဲ့ပါတယ်။

Beethoven ဟာ ဂျာမန် ကဗျာဆရာကြီး Friedrich Schiller ရဲ့ Ode to Joy ကဗျာကို အလွန်နှစ်သက်ခဲ့ပြီး၊ ဒီကဗျာကို ဂီတအဖြစ် အသက်သွင်းဖို့ စိတ်ကူးကိုသူ့ရဲ့ နှလုံးသားတနေရာမှာထဲမှာ သိမ်းထားခဲ့ပါတယ်။ နောက်ဆုံးတော့ အဲဒီအိပ်မက်ကို Symphony No. 9 ရဲ့ တေးသွားထဲမှာ ထည့်ပြီး
Collaborate လုပ်ခဲ့ပါတယ်။

ဂီတသံစဉ် သက်သက်တင်မကဘဲ လူသံ (Choir & Vocal Soloists) တွေကိုပါ ထည့်သွင်းထားပြီး Friedrich Schiller ရဲ့ ကဗျာကို အခြေခံထားတဲ့ Ode to Joy ဆိုတဲ့ သီချင်းသံစဉ်ဟာ ဒီ Symphony ရဲ့ Soul ဖြစ်လာခဲ့ပါတယ်။

အဲ့အချိန်က Orchestra ပွဲက Vocal Soloist တွေမပါသေးဘဲ Instrument Only တွေကိုပဲ တီးခတ်ခဲ့ကြတဲ့ အချိန်ပါ ။ ဒါကြောင့် ဒီတေးသွားဟာ ပုံမှန် Symphony တွေနဲ့ မတူဘဲ ကွဲထွက်ပြီး ဆန်းသစ်နေခဲ့ပါတယ်။

တင်စားပြီးပြောရရင် အသံတွေကိုမကြားရတော့ပေမဲ့ Beethoven ရဲ့ ဦးနှောက်နဲ့ နှလုံးသားထဲမှာတော့ ဂီတနန်းတော်ကြီးတခု ရှိနေခဲ့တာပေါ့ ခင်ဗျာ။

သီချင်းရဲ့ သံစဉ်တိုင်း၊ တူရိယာတစ်ခုချင်းစီရဲ့ ခံစားချက်ကို သူဟာ စိတ်အာရုံကနေခံစားပြီး တီးခတ်ရေးသားခဲ့တာ ဖြစ်ပါတယ်။ Absolutely Genius! ပါပဲ။

၁၈၂၄ ခုနှစ်၊ မေလ ၇ ရက်နေ့၊ ဗီယင်နာမြို့ (Vienna) ရဲ့ Theater am Kärntnertor မှာ Symphony No. 9 ကို ပထမဆုံးအကြိမ် ပရိသတ်ရှေ့ ပွဲထွက်ခဲ့ပါတယ်။

အဲ့ဒီခေတ်က ဗီယင်နာမြို့ဆိုတာ ဒီနေ့ခေတ် IT သမားတွေအတွက် Silicon Valley လိုမျိုး ကမ္ဘာတစ်ဝှမ်းက ထူးချွန်တဲ့ ဂီတပညာရှင်တွေနဲ့ အနုပညာရှင်တွေပြည့်တဲ့ မြို့တစ်မြို့ပေါ့ခင်ဗျာ။

အဲ့ပွဲမှာ Beethoven ကိုယ်တိုင် စင်မြင့်ပေါ်မှာ Orchestra (ဂီတဝိုင်း)ကို ဦးဆောင်ပြီး Conductor လုပ်ပေးခဲ့ပါတယ်။

သီချင်း ပြီးဆုံးသွားချိန်မှာတော့ ပရိသတ်တွေဟာ မတ်တပ်ရပ်၊ လက်ခုပ်သံတွေ မိုးခြိမ်းသလိုအားပေးခဲ့ကြပါတယ်။ ဒါပေမဲ့ နားလုံးဝ မကြားရတော့တဲ့ Beethoven ကတော့ ပရိသတ်ဘက်ကို ကျောခိုင်းထားဆဲ၊ ဂီတရသထဲမှာ နစ်မြောနေဆဲပါပဲ။ စိတ်လှုပ်ရှားနေတာလည်း ပါတာပေါ့။

အဲဒီအချိန်မှာ Caroline Unger ဆိုသူက
က Beethoven ရဲ့ လက်ကို ကိုင်ပြီး ပရိသတ်ဘက်ကို ဖြည်းဖြည်းချင်း လှည့်ပေးခဲ့ပါတယ်။ ပရိသတ်တွေရဲ့ အော်ဟစ်အားပေးမှုတွေ လက်ခုပ်သံတွေကို မျက်စိနဲ့ မြင်လိုက်ရတဲ့ အချိန်မှာတော့... မိမိဖန်တီးထားတဲ့ ဂီတရဲ့ Taste ကို ခံစားလိုက်ရပြီး ဂီတပါရမီရှင် Beethoven ရဲ့ ပါးပြင်ပေါ်မှာ ဝမ်းသာဝမ်းနည်း မျက်ရည်များ စီးကျခဲ့တယ် လို့ဆိုပါတယ်။

ဒ့ါကြောင့် Beethoven ရဲ့ Symphony No. 9 ဟာ ငယ်စဉ်ကတည်းက ရိုက်နှက်ခံခဲ့ရတဲ့ နာကျင်မှု ကံကြမ္မာရဲ့ နှိပ်စက်မှုကို အရှုံးမပေးဘဲ လူသားတို့ရဲ့ စိတ်ဓာတ်ခွန်အား၊ ချစ်ခြင်းမေတ္တာနဲ့ ပျော်ရွှင်ခြင်းတွေကို သီကျူးသွားခဲ့တဲ့ မသေဆုံးနိုင်သော ဂီတလက်ရာတစ်ခုအဖြစ် ကမ္ဘာတည်သရွေ့ကျန်ရစ်နေမှာ ဖြစ်တယ် ဆိုတဲ့အကြောင်းပြောရင်းOde to Joy တေးသွားလေးကို Repeat လုပ်ပီး အကြိမ်ကြိမ်နားထောင်နေမိပါတော့တယ် 🎻

လေးစားစွာဖြင့်
မိုကင်း 🎻

မိုကင်း 🎹

22/08/2026

VCF + NetApp 🎁

Inside the Modern Private Cloud - VCF 9 + NetAPP ONTAP

VMware by Broadcom က VMware Cloud Foundation (VCF) 9.0 ကို General Availability အဖြစ် Release လုပ်ပြီးနောက် Private Cloud Architecture အပေါ် အာရုံစိုက်မှု ပိုများလာပါတယ်။ VCF 9 ရဲ့ အဓိက Concept ကတော့ VMware Virtualization ကနေ Cloud Operating Model ပါတဲ့ Private Cloud အဖြစ် ပြောင်းလဲပေးဖို့ပါ။
ဒီအတွက် VCF Operations က Infrastructure ကို Centralized Visibility နဲ့ Operations ပေးပြီး VCF Automation ကတော့ Cloud လိုမျိုး Self-Service Provisioning ပြုလုပ်နိုင်အောင် လုပ်ပေးပါတယ်။ Private Cloud တစ်ခုတည်ဆောက်တဲ့အခါ Compute နဲ့ Network တင်မကဘဲ Storage ကလည်း အရေးကြီးပါတယ်။
ဒီနေရာမှာ NetApp ONTAP ကို External Storage အဖြစ် VCF 9 နဲ့ Integrate လုပ်လိုက်ရင် Architecture ရဲ့ Flexible ဖြစ်တဲ့အကြောင်းလေးပြောချင်ပါတယ်။

VCF မှာ Domain ဆိုတာဘာလဲ?
VCF Domain ဆိုတာ Compute, Network နဲ့ Storage Resources တွေကို Logical အရ စုစည်းထားတဲ့ Infrastructure Group တစ်ခုလို့ပြောလို့ရပါတယ်။
Management Domain က VCF Environment ရဲ့ Core Management Infrastructure ဖြစ်ပြီး VCF9 မှာ Mgmt နဲ့ Operation အများစုကို VCF Operation ,vCenter တို့ကနေ Handle လုပ်ပါတယ်။
Workload Domain ကတော့ Database, Application, Web Server, VDI, Kubernetes(Tanzu) စတဲ့ Business Workloads တွေ Run ဖို့ အသုံးပြုပါတယ်။
ဒီလိုခွဲထားတာကြောင့် Management နဲ့ Business Workloads တွေကို သီးခြားစီ Manage လုပ်နိုင်ပါတယ်။

ဒါဆို Storage ကို ဘယ်လို Handle လုပ်မလဲ?
VCF ဆိုရင် vSAN ပဲ သုံးရမယ်လို့ မဟုတ်ပါဘူး။ Client တွေမှာ ရှိပြီးသား SAN ,NAS စတဲ့ Enterprise Storage Infrastructure တွေကိုလည်း External Storage အဖြစ် ဆက်လက်အသုံးပြုနိုင်ပါတယ်။
Domain Create လုပ်တဲ့အချိန်မှာ သတ်မှတ်ထားတဲ့ Primary Storage ကို Principal Storage လို့ခေါ်ပြီး Domain Deployment ပြီးတဲ့နောက် ထပ်ထည့်တဲ့ Storage ကို Supplemental Storage လို့ နားလည်နိုင်ပါတယ်။ ဒါကြောင့် Existing ONTAP Storage ကို လိုအပ်တဲ့ Workload Domain တွေမှာ ထပ်မံအသုံးပြုနိုင်ပါတယ်။

ONTAP ကို ဘာကြောင့် သုံးသင့်တာလဲ?
အဓိကအချက်ကတော့Independent Scaling ပါ။HCI Architecture မှာ Storage တိုးချင်ရင် Compute Node ပါ ထပ်တိုးရတာမျိုး ရှိနိုင်ပါတယ်။ONTAP ကို External Storage အဖြစ် သုံးလိုက်ရင်တော့ Compute လိုရင် Compute တိုး Storage လိုရင် Storage တိုးပြီး Resource တစ်ခုချင်းစီကို သီးခြား Scale လုပ်နိုင်ပါတယ်။ Compute Capacity လုံလောက်နေပြီး Storage Capacity ပဲ မလုံလောက်တော့ရင် Server အသစ်တွေ ထပ်ဝယ်စရာမလိုဘဲ ONTAP Storage ကိုပဲ တိုးချဲ့နိုင်ပါတယ်။ ဒီအချက်က Infrastructure Cost နဲ့ Data Center Footprint ကို ပိုပြီး Control လုပ်နိုင်စေပါတယ်။

နောက်တစ်ချက်က Compute Offload ပါ
Storage-related Operations အချို့ကို ONTAP Storage ဘက်မှာ Handle လုပ်နိုင်တဲ့အတွက် ESXi Host ရဲ့ CPU Resources ကို Application Workloads အတွက် ပိုအသုံးချနိုင်ပါတယ်။ အထူးသဖြင့် Core-based Licensing Environment တွေမှာ Compute Core အရေအတွက်ကို လျှော့ချနိုင်ရင် Licensing Cost ကိုပါ သက်ရောက်နိုင်ပါတယ်။

Backup နဲ့ Disaster Recovery
ONTAP ရဲ့ Snapshot Technology ကို အသုံးပြုပြီး VM Data Protection ကို မြန်မြန်ဆန်ဆန် နဲ့ Efficient ဖြစ်အောင် လုပ်နိုင်ပါတယ်။
SnapCenter Plug-in for VMware vSphere နဲ့ အသုံးပြုတာနဲ့ vCenter Environment ထဲက VM တွေကို Backup, Restore လုပ်နိုင်ပါတယ်။
Traditional Full Backup လို Data အားလုံးကို အမြဲ Copy လုပ်စရာမလိုတာက Snapshot-based Protection ရဲ့ အားသာချက်တစ်ခုပါ။
Disaster Recovery အတွက်လည်း SnapMirror, MetroCluster, BlueXP Disaster Recovery စတဲ့ Technology တွေကို အသုံးပြုနိုင်ပါတယ်။
ဥပမာ SnapMirror နဲ့ Primary Site က Data ကို DR Site ဆီ Replicate လုပ်ထားနိုင်ပါတယ်။
ဒါကြောင့် Primary Site Failure ဖြစ်ခဲ့ရင် Secondary Site မှာ Workload တွေကို ပြန်လည် Run နိုင်ဖို့ Architecture တည်ဆောက်ထားနိုင်ပါတယ်။
VCF + ONTAP Architecture ကို
အကြမ်းဖျင်းအားဖြင့် ဒီလိုမြင်နိုင်ပါတယ်။

Compute > VMware ESXi ,VCF
Network > VMware + Physical Network
Storage > NetApp ONTAP
Management > VCF Management
Operations >VCF Operations
Network Virtualization > NSX

ဒီ Components တွေကို ပေါင်းစပ်လိုက်တဲ့အခါ ရိုးရိုး VMware Cluster တစ်ခုထက် ပိုတဲ့ Private Cloud Platform တစ်ခု ဖြစ်လာပါတယ်။ အနည်းငယ် ပြန်ချုံ့ရရင်
VCF 9 က Private Cloud ရဲ့ Compute, Network, Management နဲ့ Automation ,Operation ကို စုစည်းပေးပီး NetApp ONTAP ကတော့ Enterprise Storage, Data Protection, Backup နဲ့ Disaster Recovery ကို ဖြည့်ဆည်းပေးပါတယ်။

ဒါကြောင့် VMware Cloud Foundation 9 + NetApp ONTAP ဆိုတာ VMware Infrastructure ထက် ပိုပြီး Flexible, Scalable & Resilient Private Cloud Architecture တစ်ခုအဖြစ် စဉ်းစားနိုင်ပါကြောင်း ပြောရင်း ဒီမှာရင်နားပါရစေ ခင်ဗျာ။ ဖတ်ရှုမှု အတွက် ကျေးဇူးတင်ပါတယ်

မင်းကို

ATG SYSTEMS
📍 Head Office
B3, Kan Street, Kan Yeik Mon Housing,
Ward(10), Hlaing Township, Yangon.

📱 +959447701033
📧 [email protected]

05/08/2026

⚔️ CLASH of the VMware Titans 🛡️

📠 I wrote this article 2 years ago.

🎻 vSphere Standard နေဝင်ချိန် (သို့) Beyond the vSphere Standard

Broadcom ရဲ့ Global Simple Licensing Portfolio ကြောင့် April 10, 2025 က စလို့ ကျွန်တော်တို့ (Asia Pacific နဲ့ Japan) APJ Region တွေမှာ vSphere Standard License ကိုအသစ်အနေနဲ့ Purchasing လုပ်ခွင့်ပေးတော့မှာ မဟုတ်တော့ပါဘူး။ ဒါပေမယ့် Region တချို့မှာတော့ မကြာသေးခင်အချိန်ထိ Still Remains ဖြစ်နေဦးမှာပါ။

🎸 The Dramatic Tuning Point
Nov 22, 2023 မှာ Broadcom က VMware ကို အပြီးသတ် ဝယ်ယူပြီးနောက်ပိုင်း အရင် VMware ရဲ့ Perpetual License Model ကို ဖျက်သိမ်းပြီး Subscription-Based license ပုံစံပြောင်းလဲသတ်မှတ်ခဲ့ပါတယ်။

🎹 Perpetual vs Subscription

Perpetual License
VMware License ကို တစ်ကြိမ်သာ ဝယ်ယူပြီး အမြဲတမ်းအသုံးပြုနိုင်သော Lifetime License Model တစ်ခုပဲဖြစ်ပါတယ်။သို့သော် “Lifetime” ဖြစ်ပေမယ့် Service & Support (SnS) ကို ဆက်လက်ရရှိဖို့အတွက်တော့ လိုင်စင် သက်တမ်းတိုးခြင်း (Renewal) လုပ်ဖို့ လိုအပ်ပါတယ်။ ယနေ့အချိန်မှာတော့ VMware ကို Broadcom ဝယ်ယူပြီးနောက် SnS Renewal ကို ထပ်မံခွင့်မပြုပဲ ရပ်ဆိုင်းလိုက်ပြီ ဖြစ်ပါတယ်။ ဒါကြောင့် Perpetual License အသုံးပြုနေသည့် customer များအနေနဲ့မိမိလုပ်ငန်းလိုအပ်ချက်နှင့် ကိုက်ညီမည့် Subscription-based License အသစ်တစ်ခုခုကို ဝယ်ယူဖို့လိုလာပါတယ်။ (E.g. VMware vSphere Foundation)

🎶 Subscription license
1 year, 3 years, 5 years စသဖြင့် (Yearly) သက်တမ်းအလိုက် ဝယ်ယူရတဲ့ Term-Based Model အမျိုးစားဖြစ်ပါတယ်။ တချို့က Multi-Year Term လို့လည်း သုံးပါတယ်။ license (expired) သက်တမ်းတခုရှိပြီး သက်တမ်းအသစ်တိုးမယ်ဆို License Renewal လုပ်ဖို့လိုပါတယ်။ Subscription license ရဲ့ အားသာချက် တချို့ကတော့ Latest Version , Security Paths နဲ့ အသစ်အသစ်သော Features တွေကို အမြဲရနိုင်ပီး ကိုယ့်ရဲ့ Infra Structure မှာ (Always Up to Date) ဖြစ်နေစေလို့ Industry Security Standards ဖြစ်တဲ့ (PCI-DSS ,ISO etc.) တွေကိုပါ အလွယ်တကူ Compliant ဖြစ်စေတဲ့ အချက်တွေပါပဲ။

🥁 New Magic Number - 72 Core Era
Broadcom ရဲ့ နောက်ထပ် Key Major Changes ကတော့ license အသစ်ဝယ်ယူမှု (သို့) သက်တမ်းတိုး လုပ်ငန်းစဉ်တွေအတွက် Minimum အနည်းဆုံး 72 - Cores based licensing ဝယ်ဖို့ April 10, 2025 နောက်ပိုင်းကစလို့ Policy အသစ်ထုတ်လိုက်တာပါ။
ဒီ Policy ကိုသက်ရောက်တဲ့ Regions တွေကတော့ EMEM (Europe , Middle East , Africa) နဲ့ (APJ) (Asia, Pacific & Japan) Regions တွေဖြစ်ပါတယ်။ ဥရောပလို (EU) နဲ့ EMEA region တွေမှာတော့ Partner တွေနဲ့ Customer တွေရဲ့ Community Backlash ကြောင့် Broadcom ဖက်က 72-Core Rule ကို 16 Core Per CPU နဲ့ Reversed ပြန်လုပ်တယ်လို့တချို့ Blogs တွေမှာတွေ့ရပါတယ်။ ဒါပေမယ့် Broadcom ဖက်က Statement ထုတ်ပြီးအတိအလင်း Public Announce လုပ်တာမျိုးတော့ မတွေ့မိသေးပါဘူး။ (Asia Pacific & Japan) APJ Region တွေမှာတော့ ဒီ Policy က အကြုံးဝင်ဆဲပါ။

🎵 LICENSING REIMAGINED
Company A ဟာ Broadcom မှအသစ်ပြောင်းလဲထားတဲ့ VMware License ကို ပထမဆုံး အကြိမ် ဝယ်ယူချင်တယ် ဆိုကြပါစို့။
ဥပမာ။ ။ Company A ကသူ့ရဲ့ new infrastructure အတွက် CPU 48 Cores လိုချင်ပါတယ်။ သို့သော် Company A သည် New Buyer ဖြစ်သောကြောင့် Minimum 72-Core License ကို မဖြစ်မနေ ဝယ်ရမှာ ဖြစ်ပါတယ်။ ဒီအခြေအနေမှာ သုံးစွဲမယ့် Core နည်းပေမယ့် Broadcom Policy အရ 72 Cores တိတိကို လိုအပ်တယ်။ နောက်တခုက VMware ကို ခုမှ စသုံးမယ့်သူ New Buyer တော့ မဟုတ်ဘူး ဒါပေမယ့် လက်ရှိသုံးနေတဲ့ Subscription က သက်တမ်းကုန်လို့ ပြန်လည်သက်တမ်းတိုးခြင်း (Renewal Process) ကိုလည်း Broadcom ရဲ့ ပေါ်လစီအသစ်အရ New Buyer လို့သက်မှတ်တဲ့ အတွက် Minimum 72 Cores ဝယ်ယူဖို့ မဖြစ်မနေလိုအပ်ပါတယ်။

Expired License? You’re Not Renewing – You’re a New Buyer.

🪗 STAY ACTIVE , BUY LESS

နောက်တခုက Company A က အရင်က 16 Core Subscription License ကိုဝယ်ယူ အသုံးပြုခဲ့ပြီး Workload အသစ်တိုးလာတာကြောင့် နောက်ထပ် 48 Core ကို ထပ်မံဝယ်ချင်တယ်ဆိုပါစို့။ Broadcom ရဲ့ Policy အသစ်အရ Subscription Contract က Active အခြေအနေမှာ ဆက်လက် အလုပ်လုပ်နေဆဲဖြစ်တယ်ဆိုရင် New Buyer အဖြစ်မသတ်မှတ်ဘဲ Company Aရဲ့ လိုအပ်ချက်ဖြစ်တဲ့ 48 Cores ကို Broadcomရဲ့ 72 Core Minimum Policy နဲ့ ထပ်ဝယ်စရာ မလိုဘဲဝယ်ယူလို့ရမှာဖြစ်ပါတယ်။။ ဒါက Broadcom ရဲ့ ပြောင်းလဲလိုက်တဲ့ Policy ပုံစံအသစ်ကြောင့်ပဲဖြစ်ပါတယ်။

🪕NEW LICENSING PHILOSOPHY
🤘vSphere Cloud Foundation ✅
🤘VMware vSphere Foundation ✅
🤘vSphere Standard (EOS) ❌
🤘vSphere Essentials /Plus (EOS) ❌

VMware Broadcom က သူတို့ရဲ့ ပြောင်းလဲလိုက်တဲ့ license Structure အရ vSphere Standard , vSphere Essentials စတဲ့ traditional edition တွေကို (Officially Discontinued) လုပ်ပြီး Suite-Based Model ပုံစံဖြစ်တဲ့-vSphere Cloud Foundation (VCF)နဲ့ VMware vSphere Foundation (VFF) တို့ကိုသာအဓိက သုံးစွဲဖို့ ရည်ရွယ်တာဖြစ်ပါတယ်။

🎙️ တခန်းရပ် EPL
Essentials Plus License ကလည်း2024, November 11 ကစပြီး (End of Sale) လို့သတ်မှတ် ပြီးသားဖြစ်ပါတယ်။ လက်ရှိမှာ Essentials Plus သုံးနေတဲ့ Customer တွေကိုတော့ ဒီလိုင်စင်ရဲ့ subscription သက်တမ်းကုန်ချိန်ထိ ဆက်လက်သုံးဖို့ခွင့်ပြုထားပါတယ်။သို့သော် ထပ်မံ core တိုးဖို့ (additional capacity) နဲ့ subscription term ကို renew လုပ်ဖို့တော့ မရနိုင်တော့ပါ။ ထပ်တိုးအသုံးပြုဖို့ လိုတဲ့ Customer တွေအနေနဲ့တော့ VCF (vSphere Cloud Foundation) နဲ့ (VMware vSphere Foundation) ထဲက တစ်ခုခုဝယ်ယူဖို့အကြံပြုထားပါတယ်။


📝 Key Notes : VMware ရဲ့ license အသစ်တွေက Per Core Based တွေဖြစ်တဲ့အတွက် vCloud Director နဲ့ vSANတို့လို အရေတွက် (PerVm)နဲ့ အရွယ်စားအလိုက်(PerTiB) နဲ့ ဝယ်ရတဲ့ Usage-Based Products တွေ ပေါ်မှာတော့ ဒီ Policy က မသက်ရောက်ပါဘူး။

⚔️The Clash of VMware Titans: VCF & VVF
VCF ( VMware Cloud Foundation) VFF ( vSphere Foundation) တွေနဲ့ ဘယ်တွေလုပ်လို့ရလဲ စတဲ့ Products နဲ့ features ပိုင်းတွေကို အနည်းငယ် ဆက်လေ့လာကြည့်ရအောင်ခင်ဗျာ။

🎷V.C.F : VSPHERE CLOUD FOUNDATION (SUITE)
VCF ဆိုတာက VMware ရဲ့ Private Cloud Solutions ဖြစ်ပြီးတော့ Compute , Network Vis , Storage , Security နဲ့ Automation တွေအားလုံးပါဝင်တဲ့ Full Stack license (Suite) Bundle တခုဖြစ်ပါတယ်။ NSX သုံးမယ်ဆို VCF ကိုရွေးချယ်သင့်ပါတယ် ။

🪘Craftsmanship
ခုနောက်ပိုင်းဆို Companies တွေ တော်တော်များများက သူတို့ရဲ့ Applications တွေကို Microservices Architecture ကို အသုံးပြုပြီး Develop လုပ်လာကြပါတယ်။ အဲ့အတွက် K8S ကိုသုံးပြီး Develop & Manage လုပ်ပါတယ်။ ဒီချိန်မှာ K8S Cluster တွေကို ဘယ် Infra အမျိုးစားကိုသုံးပြီး Setup လုပ်မလဲ ဆိုတဲ့ IT Challenging ရှိလာပါတယ်။ အဲ့ အတွက် vSphere with Tanzu ( Tanzu K8s Grid) ကရွေးချယ်စရာအဖြေတခုဖြစ်လာပါတယ်။Tanzu ဆိုတာက ရှိပြီးသား vSphere Infra Structure ပေါ်မှာပဲ K8S (Kubernetes) ကို သုံးပြီး Container Workload တွေ အလွယ်တကူ Built Up လုပ်တဲ့ Product ဖြစ်လို့ပါ။ ဒါကြောင့် (K8S နဲ့ Modern Cloud Native Apps) တွေအတွက် Data Center တခုတည်ဆောက် ချင်တယ်ဆိုရင်လည်း VCF Suite ကအကောင်းဆုံး ဖြေရှင်းချက် ဖြစ်လာပါတယ်။

🪇V.C.F : VSPHERE CLOUD FOUNDATION (SUITE)
နောက် VCF မှာက vSphere , vCenter Management , Advanced Network Virtualization (NSX), Storge Virtualization (vSAN) အပြင် VMware ရဲ့ Reporting & Monitoring System ဖြစ်တဲ့ VMware Aria Operations Suite (formerly vRealize Operation, Logs Insight) စတဲ့ license တွေအားလုံး ပါဝင်ပါတယ်။

🎶V.V.F: VMWARE VSPHERE FOUNDATION (SUITE)

VMware vSphere Foundation ကလည်း Traditional VM Workloads တွေအတွက် သင့်တော်ရုံသာမက Modern Apps Workloads (Kubernetes (Tanzu) ကိုလည်း Built-In Support လုပ်တဲ့အတွက် Flexible ဖြစ်တဲ့ future-Proof Edition တခု ဖြစ်ပါတယ်။ VCF မှာတော့ တချို့ Features တွေအတွက် Add- On license တွေ Optionally ထပ်မံဝယ်ယူရမှာ ဖြစ်ပါတယ်။

🎻ဒီ Article လေးကနေ VMware Broadcom ရဲ့ Modern licensing Structure နဲ့ Subscriptions အကြောင်းနဲ့ သက်ဆိုင်တဲ့ Knowledge တွေရမယ်လို့ မျှော်လင့်ပါရင်း Article လေးကို ဒီမှာတင်နားပါရစေ ခင်ဗျာ။

လေးစားစွာဖြင့်
မင်းကို

28/07/2026

THE SYMPHONY Of TANZU 🎻🎹

vSphere with Tanzu ဆိုတဲ့ Concert Hall ထဲမှာ Containers, Runtimes, Habor, Kubernetes တွေကို Conductor တစ်ယောက်ဦးဆောင်ညှိပေးလိုက်တဲ့အခါ "Beethoven" ရဲ့ " Symphony 9" ဖြစ်တဲ့ "Ode To Joy " 🎶 လို အလွန်တရာလှပတဲ့ Modern Applications တေးသွားသံစဉ်တွေ ထွက်လာမှာပဲ ဖြစ်ပါတယ်

စိတ်ဝင်စားရင် တပုံချင်းထောက်ပြီးဖတ်ပါ 📚

16/07/2026

The KING ဘလူးတု(သို့) Viking တွေရဲ့ကမ္ဘာ 🪓🛡️ 👑

ဒီနှစ် World Cup မှာ ကျွန်တော်အတော်လေး စိတ်ဝင်စားမိတာကတော့ ..ဆံပင်ရွှေဝါရောင် ကပိုကရိုလေးနဲ့၊ ဂိုးသွင်းပြီးရင် ကလေးလို အပြစ်ကင်းကင်း ပြုံးတတ်တဲ့ Erling Haaland ဦးဆောင်တဲ့ နော်ဝေအသင်းက Viking Rowing Celebration လုပ်ပြတဲ့ မြင်ကွင်းပါပဲ။ ရှေးခေတ် ဗိုက်ကင်းတွေရဲ့ Legacy တခုကို တကမ္ဘာလုံးအတိုင်းအတာနဲ့ ကြည့်ရှူနေတဲ့ ပြိုင်ပွဲမှာ Celaebration အနေနဲ့ပြန်မြင်ရတာက တကယ်လေးမိုက်တယ်ဗျ။

Vicking တွေလို့ဆိုမှ အေဒီ ၁၀ ရာစုဝန်းကျင်မှာ ဒိန်းမတ် 🇩🇰 ကို အုပ်ချုပ်ခဲ့တဲ့ King Harald Bluetooth Gormsson အကြောင်းနည်းနည်းပြောရဦးမယ်။ ကျွန်တော်တို့ ဒီနေ့သုံးနေတဲ့ ဘလူးတု နာမည်နဲ့ သွားတူမနေဘူးလားဗျ?

King Harald ကို Bluetoothလို့ ဘာကြောင့်ခေါ်ခဲ့တာလဲဆိုတာတော့ သမိုင်းပညာရှင်တွေကြား ငြင်းခုံနေကြတုန်းပဲ ဖြစ်ပေမယ့် အများပြောကြတဲ့ ယူဆချက်တစ်ခုကတော့ သူက Blueberry သီးတွေ အလွန်အမင်း စားလေ့ရှိလို့ သွားအရောင်ညိုပြာနေခဲ့တာကြောင့်လို့ ဆိုကြပါတယ်။ ဒါပေမယ့် သူ့ကို သမိုင်းမှာ ကျော်ကြားစေခဲ့တာက ဒီ အပြာရောင်သွားကြောင့် မဟုတ်ပါဘူး။

သူ့ရဲ့ အကြီးမားဆုံးသော စွမ်းဆောင်ရည်က အချင်းချင်း အမြဲတိုက်ခိုက်ပြီး ကွဲပြားနေတဲ့ Denmark နဲ့ Norway ဒေသတွေကို တစ်ခုတည်းဖြစ်အောင် စုစည်း ပေးနိုင်ခဲ့တဲ့ ဘုရင် 👑 တပါး ဖြစ်တာကြောင့်တဲ့ခင်ဗျ။

၁၉၉၀ ပြည့်နှစ် အလယ်ပိုင်းမှာ Ericsson, Intel, Nokia, IBM နဲ့ Toshiba တို့က Phone Computer နဲ့ Electronic Devices တွေကို ကြိုးမဲ့ Short-range နည်းလမ်းနဲ့ အချင်းချင်း ချိတ်ဆက်နိုင်မယ့် နည်းပညာအသစ်တစ်ခုကို ဖန်တီးဖို့ ကြိုးစားနေခဲ့ကြပါတယ်။
အဲဒီအချိန်မှာပဲ Intel ရဲ့ အင်ဂျင်နီယာတစ်ယောက်ဖြစ်တဲ့ Jim Kardach က ဗိုက်ကင်းသမိုင်းကြောင်းတွေကို ဖတ်နေရင်း အလင်း 💡ပွင့်သွားခဲ့ပါတယ်။

King Harald က အကွဲကွဲအပြဲပြဲဖြစ်နေတဲ့ မျိုးနွယ်စုတွေကို တစ်စုတစ်စည်းတည်းဖြစ်အောင် စုစည်းပေးခဲ့သလိုမျိုး... ငါတို့ တီထွင်လိုက်တဲ့ နည်းပညာကိုလည်း မတူညီတဲ့ ပစ္စည်းတွေကို short-range wireless link နဲ့ တစ်စုတစ်စည်းတည်း ချိတ်ဆက်ပေးမှာပဲ ဆိုပီးပေါ့ဗျာ။

ဒါကြောင့် သူတို့ရဲ့ Project Codename အဖြစ် Bluetooth လို့ ယာယီ ခေါ်တွင်ခဲ့တာပါ။
မူလက ယာယီနာမည်သာ ဖြစ်ပေမယ့် နောက်ပိုင်း တခြား official နာမည်တွေဖြစ်တဲ့ RadioWire တို့၊ PAN (Personal Area Network) တို့ကို ပြောင်းဖို့ ကြိုးစားသေးပေမယ့် ဒီနာမည်ကပဲ ကမ္ဘာကျော်ပြီး လူသိအများဆုံး Brand ဖြစ်သွားခဲ့ပါတယ်။

🔷 Bluetooth Logo နောက်ကွယ်က လျှို့ဝှက်ချက်တခု

ယနေ့ ဖုန်းတိုင်းမှာ ကျွန်တော်တို့ မြင်နေကျ Bluetooth Logo ဟာ ဒီဇိုင်းလှဖို့သက်သက် ဖန်တီးထားတာ မဟုတ်ပါဘူး။

အဲတာက ဗိုက်ကင်းခေတ်က အသုံးပြုခဲ့တဲ့ Runic alphabet ထဲက H (ᚼ) နဲ့ B (ᛒ) rune နှစ်ခုကို ပေါင်းစပ်ဖန်တီးထားတာဖြစ်ပြီး၊ ဒါဟာ ဒိန်းမတ်ဘုရင် Harald Bluetooth ရဲ့ အမည်အစစာလုံး H နဲ့ B ဆိုတဲ့ Bluetooth Logo လေး တခုဖြစ်လာခဲ့တာပါ။

တကယ်တော့ Bluetooth ဆိုတာ နည်းပညာတစ်ခုရဲ့ နာမည်နာမတခုထက် ပိုပါတယ်။
ရှေးခေတ်မှာ ကွဲပြားနေတဲ့ လူတွေကို စုစည်းပေးခဲ့တဲ့ 🤴 ဘုရင်တစ်ပါးရဲ့ နာမည်ကို ယူပြီး၊ ဒီနေ့ခေတ်မှာ မတူညီတဲ့ Devices အမျိုးမျိုးကို ကြိုးမဲ့စနစ်နဲ့ အချင်းချင်း ပေါင်းကူးပေးတဲ့ နည်းပညာအဖြစ် အသက်ဝင်လာတဲ့ စိတ်ဝင်စားဖို့ကောင်းတဲ့ Technology Story တစ်ပုဒ်ပဲ ဖြစ်ပါတယ်။

တစ်ခါတလေ နေ့တိုင်းနှိပ်အသုံးပြုနေတဲ့ Bluetooth Icon လေးရဲ့ နောက်ကွယ်မှာလည်း နှစ်ပေါင်း ၁,၀၀၀ ကျော်က သမိုင်းကြောင်းတစ်ခု ဝှက်ထားတတ်တဲ့ ဆိုတဲ့ အကြောင်းလေး ပြောရင်း Sharira ရဲ့ Dai Dai အစား ကျားပေါက်ရဲ့ Bluetooth သီချင်းလေး နားထောင်မိနေလေရဲ့ ။ ဘီယာလေး သောက်ရင်း Vicking တွေရဲ့ Highlights လေး ပြန်ကြည့်နေမိတာတော့ ဘယ်လိုပြောမလဲ ဆောင်းဦးလှိုင်ရဲ့ အပိုဆုပေါ့ဗျာ။

မိုကင်း ။ 🤘

15/07/2026

Voice ☎️

S.I.P တံခါးမျာ: 🚪
Enterprise Cisco Call Center Solution & SIP Security

Enterprise Cisco Call Center Solution တစ်ခုကို စသုံးမယ်ဆိုရင် Voice Gateway နဲ့ IPPBX (Cisco Call Manager) နဲ့ တွဲသုံးဖို့အတွက် Gateway Protocol (၃) မျိုး ရှိပါတယ်။ SIP, H.323 နဲ့ MGCP Protocol တို့ပဲ ဖြစ်ပါတယ်။
ဒီ Protocol ၃ ခုထဲက တစ်ခုခု ရွေးရမယ်ဆိုရင် ဘယ် Protocol ကို ရွေးချယ်သင့်သုံးလဲ? လို့ မေးလာရင်တော့... အဖြေက It Depends On You လို့ပဲ ဖြေရမှာပါ။ ဒါဆို ဘာလို့ ဆက်ဖတ်နေဖို့ လိုဦးမှာလဲ? မေးလာရင် ရှင်းပြပေးပါ့မယ်။
Voice Architecture တစ်ခုကို Design မချခင် အရင်ဆုံး Technical လိုအပ်ချက်တွေကို သေချာနားလည်ဖို့လိုပါတယ်။ Technical လိုအပ်ချက်တွေဟာ Solution တစ်ခုကို ရှာဖို့အတွက် တိုက်ရိုက် အထောက်အကူပြုစေသလို၊ ရွေးချယ်တဲ့ Design ပိုင်းကလည်း Business ရဲ့ Requirement နဲ့ Meet ဖြစ်ဖို့ လွန်စွာ အရေးပါလှပါတယ်။
What is Voice Gateway?
Voice Gateway ဆိုတာ ကိုယ့်ရဲ့ Enterprise VoIP Network နဲ့ Telco တွေ (ဥပမာ - MPT, ATOM, U9) ရဲ့ PSTN, SIP Trunk စတဲ့ ခြားနားတဲ့ Connectivity Method တွေကို ကြားခံ ချိတ်ဆက်ပေးနိုင်တဲ့ Interfacing Device လို့ ဆိုရမှာပါ။
☎️ Historical Context
2015/16 ဝန်းကျင်က SIP Trunking လိုင်းတွေကို Telco တွေကနေဝယ်ဖို့ အနည်းငယ်ခက်ခဲခဲ့တဲ့ အချိန်တွေမှာ PSTN Network (CO) Landline ဖုန်းလိုင်းတွေနဲ့ပဲ အားထားခဲ့ကြရပါတယ်။ SIP Trunking ဝယ်လို့ရခဲ့မယ်ဆိုရင်တောင် Pure SIP Service ကို မရခဲ့ဘဲ SIP-I ကိုပဲ Support လုပ်ခဲ့တဲ့အတွက် Cisco Router တွေနဲ့ အဆင်မပြေခဲ့ပါဘူး။ (Note: Cisco က အဲ့ဒီအချိန်က SIP-I ကို Support မလုပ်ခဲ့ပါ။)
လက်ရှိအချိန်မှာတော့ Telco တွေကနေ SIP Trunking လိုင်းတွေ အလွယ်တကူသုံးလို့ရသော်ငြားလည်း PSTN နဲ့ GSM Gateway တွေကို သုံးနေကြဆဲဆိုတာ မေ့ထားလို့မရပါဘူး။ PSTN/ISDN (T1, E1) Network ကို သုံးမယ်ဆိုရင် ITSP ကနေ (IAD ကတစ်ဆင့်) တိုက်ရိုက်ဝင်လာမယ့် RJ11/RJ45 Ports တွေ တပ်ဆင်ဖို့အတွက် FXO, T1 Interface Card စတဲ့ သက်ဆိုင်ရာ Modular Card တွေကို Voice Gateway Router မှာ စိုက်ပေးရပါတယ်။ Call Routing နဲ့ Dial Plan တွေကိုတော့ Voice Gateway က လုပ်ဆောင်ပေးပြီး၊ IPPBX Server (CUCM) ကတော့ Middle Man အနေနဲ့ Session Establish လုပ်ပေးတာမျိုးပါ။
မှတ်ချက်: 📝 ကျွန်တော်တို့ဆီမှာ 🇲🇲 ISDN Digital Network ကို ကျယ်ကျယ်ပြန့်ပြန့် သုံးစွဲခဲ့ခြင်း မရှိဘဲ PSTN (Analog) မှတစ်ဆင့် SIP Trunk (IP-based) သို့ นည်းပညာအရ Generation တစ်ဆင့်ကျော် (Leapfrogging) ခုန်ကူးခဲ့ကြခြင်း ဖြစ်ပါတယ်။
☎️ Modern Call Flow ဥပမာများ
• Telecom > Voice Gateway > IPPBX > SIP Phones
• (U9) SIP Trunk/PSTN > SBC > CUCM > SIP Phones
☎️ SBC ကို ဘယ်လိုသုံးကြမလဲ?
SIP Trunking လိုင်းကိုဝယ်သုံးမယ်ဆိုရင် Call Manager ကို Direct Connect လုပ်ပြီး သုံးလို့ရပေမယ့်၊ DDoS Attack, Toll Fraud Attack တွေကနေ ကာကွယ်ဖို့၊ Protocol Interworking နဲ့ Media Transcoding တွေ လုပ်ဆောင်နိုင်ဖို့အတွက် SBC (Session Border Controller) တစ်ခု မဖြစ်မနေ လိုအပ်လာပါတယ်။
SBC ဆိုတာကရော ဘာလဲ ဆိုရင် အရမ်းမတွေးပါနဲ့။ Cisco 8000 Series Edge Platform ပေါ်မှာ CUBE (Cisco Unified Communications Border Element) License run လိုက်ရင် SBC ပါပဲ။ VoIP ရဲ့ Voice Traversal Firewall ပါပဲ။
☎️ Why SBC ? (Media Transcoding နဲ့ Toll Fraud ရဲ့ အန္တရာယ်)
Media Transcoding: ကိုယ့်ရဲ့ Internal VoIP က G.711 Codec ကို သုံးထားပြီး Provider ဘက်က G.729 Codec ကို သုံးထားမယ်ဆိုရင် ကြားထဲကနေ Media Transcoding (Codec ပြောင်းလဲပေးခြင်း Process) လုပ်ပေးဖို့ လိုပါတယ်။ ဒါကို SBC က ကောင်းကောင်း လုပ်ဆောင်ပေးနိုင်ပါတယ်။
Toll Fraud (အကြီးမားဆုံး အန္တရာယ်): Attacker တော်တော်များများဟာ Phone System တွေကို Exploit လုပ်ဖို့ အမြဲအားစိုက်နေကြပါတယ်။ Phishing Scams တွေ သုံးပြီး Unauthorized Access ရဖို့ User နဲ့ Admin တွေကို ပစ်မှတ်ထားတတ်ကြပါတယ်။
What is Toll Fraud?
Toll Fraud ဆိုတာက Hacker တွေက Internet ပေါ်ကနေ ကိုယ့် VoIP Network ထဲ ခိုးဝင်သုံးပြီး International Calls (နိုင်ငံခြားဖုန်းတွေ) ကို အလုအယက် ခေါ်ဆိုသွားတာပဲ ဖြစ်ပါတယ်။ ကိုယ်မသိလိုက်ခင်မှာ သုံးသွားတဲ့ ဒီလို Long-Distance Call ဘေလ်တွေအတွက် ကိုယ့် Organization က Toll Charges တွေကို သိန်းပေါင်းများစွာ စိုက်လျော်ရပါလိမ့်မယ်။
နာမည်ကျော် Trend Micro ရဲ့ အဆိုအရ Telco Toll Fraud တွေကြောင့် ကမ္ဘာတစ်ဝန်းမှာ ဆုံးရှုံးမှုတန်ဖိုး USD 37 Billion တောင် ရှိခဲ့တယ်လို့ ဆိုပါတယ်။ နောက်ပြီး Caller ID Spoofing, Eavesdropping နဲ့ Social Engineering Attacks တွေ သုံးပြီးတော့လည်း VoIP Hacking တွေ လုပ်နိုင်ပါသေးတယ်။
⚠️ Security Vulnerability
Unprotected Cisco CME (IP-PBX) Router တစ်လုံးကို Public Internet ပေါ်မှာ Set up လုပ်ကြည့်ရင် Attack ခံရဖို့ ခန့်မှန်းခြေ မိနစ် ၅၀ ပဲ ကြာပါတယ်။ Weak Password ကို Break out လုပ်ဖို့ နောက်ထပ် ၁၀ မိနစ်နဲ့ Outbound Call တွေကို ခိုးပြီး Dial Out လုပ်ဖို့ ၂ မိနစ် စုစုပေါင်း မိနစ် ၆၀ (၁ နာရီ) အတွင်းမှာတင် ကိုယ့် System တစ်ခုလုံး Hacking လုပ်ခံရနိုင်ပါတယ်။
လူကြီးမင်းကိုယ်တိုင် SIP Video Endpoint တစ်လုံးကို Untrusted Network မှာ SIP Port တွေဖွင့်ပြီး စမ်းကြည့်ပါ။ မိနစ်ပိုင်းအတွင်းမှာတင် Spam Call / Ghost Calls ရာနဲ့ချီပြီး ဝင်လာတာမျိုး ကြုံရပါလိမ့်မယ်။ SIP Scanner တွေထဲမှာတော့ Freeware ဖြစ်တဲ့ SIPVicious Tool က နာမည်ကျော်ပါတယ်။

☎️ SIP is another piece of the puzzle
Session Border Controller (SBC) Gateway ကို Cisco မှာတော့ CUBE (Cisco Unified Communications Border Element)လို့ ခေါ်ပါတယ်။ CUBE ဟာ VoIP အတွက် သီးသန့် ဖန်တီးထားတာ ဖြစ်တဲ့အတွက်၊ SIP ရဲ့ Layer 7 က SDP Message ကြောင့် ဖြစ်တတ်တဲ့ One-Way Call Issue (SIP behind NAT Problem)ကို ရှင်းပေးနိုင်တဲ့ NAT-Traversal Firewall တစ်လုံးလို့လည်း ပြောနိုင်ပါတယ်။
☎️ SIP Behind NAT (Technical Insight)
ဖုန်း A ကနေ ဖုန်း B ကို ခေါ်လိုက်တယ် ဆိုပါစို့။ ဖုန်း A (SIP Phone) ကနေ စပြီး Initiate လုပ်လိုက်တဲ့ SDP Message ရဲ့ Contact List ထဲမှာ IP ဖုန်းရဲ့ Private IP ပါသွားပါတယ်။ Layer 3 NAT က Address ကို Public IP အဖြစ် ပြောင်းပေးလိုက်နိုင်ပေမယ့်၊ ဖုန်း B ရဲ့ Destination End ရောက်တဲ့အခါ ပြန်ပို့ရမယ့် Contact Address က ဖုန်း A ရဲ့ Private IP ပဲ ဖြစ်နေပါတော့တယ်။ L3 NAT က ပြောင်းလဲလိုက်တဲ့ IP နဲ့ ကွဲပြားနေတဲ့အတွက် ဖုန်း A ရဲ့ (Non-Routable ဖြစ်တဲ့) Private IP ဆီကို Voice Packet က ပြန်မရောက်နိုင်တော့ဘဲ Packet Discard ဖြစ်သွားပါတယ်။
ဒါဟာ Signaling အပိုင်းမှာ အဆင်ပြေပြေ ချိတ်ဆက်နေပေမယ့်၊ Media (အသံ) သွားတဲ့အချိန်မှာ တစ်ဖက်ကပြောတာပဲ ကြားရပြီး၊ တစ်ဖက်က ပြန်မကြားရတဲ့ One-Way Audio Problem ကို ဖြစ်စေတာပါ။
"ကိုယ်ပေးသော်လည်း ပေးတိုင်းပြန်မရတာ... Voice လို့ ခေါ်သလားပေါ့ဗျာ..."
☎️ Conclusion
ပုံမှန် Firewall/NAT ဟာ Layer 3 Address ကိုပဲ Translate လုပ်နိုင်ပေမယ့်၊ CUBE ကတော့ Layer 3 ရော Layer 7 (Application Layer) မှာပါ Address ကိုပါ Translate လုပ်ပေးနိုင်ပါတယ် (SIP ဟာ L7 Protocol တစ်ခုပါ)။ ဒီအတွက်ကြောင့် CUBE ကို သုံးကြရတာပါ။
ပေးချင်တဲ့ မက်ဆေ့ကတော့ ကိုယ်တကယ်သုံးနေတာက SIP Trunking Service ဆိုရင် Security အတွက်ရော NAT Problem တွေအတွက်ပါ CUBE (SBC) ကို ရွေးချယ်တာက အသင့်တော်ဆုံး ဖြစ်ပါတယ်ဆိုတဲ့ အကြောင်းလေးပြောရင်း ဒီမှာတင် နားပါရစေ။ ဖတ်ရှုမှုအတွက်လည်း ကျေးဇူးတင်ပါတယ်။
လေးစားစွာဖြင့်၊
မင်းကို
Senior Solutions Consultant

Creation
Innovation
Revolution
That's Collaboration.

26/06/2026

Data Loss Prevention 🛡️

DLP Story 🔐 : Data Loss Prevention

Next Generation Firewall တွေ တပ်ထားတယ်။ Endpoints Protection တွေ သုံးထားတယ်။ Multi-factor Authentication တွေ ဖွင့်ထားတယ်။ ဒါပေမယ့် Organization တွေရဲ့ အရေးကြီးဆုံး၊ အဖိုးတန်ဆုံးဖြစ်တဲ့ မရှိမဖြစ် Crown Jewel Data တွေကတော့ နည်းလမ်းမျိုးစုံနဲ့ အပြင်ကို ထွက်နေနိုင်ဆဲ ဖြစ်ပါတယ်။ ဟုတ်ပါတယ်။ Cyber Security Team တွေအတွက် အခက်ခဲဆုံး Challenge တွေထဲက တစ်ခုကတော့ Data Leakage ဖြစ်ခြင်းပါပဲ။

အရင်တုန်းက Data Leakage ဆိုတာ USB Stick ထဲ Copy ကူးတာ၊ e-mail နဲ့ ပို့တာလောက်ကိုပဲ စိုးရိမ်ရပါတယ်။ ယနေ့အချိန်မှာ insider တစ်ယောက်ဟာ Data တွေကို Leak လုပ်ဖို့အတွက် USB Stick တွေ၊ External Disk တွေထဲ တကူးတက ကူးယူနေဖို့တောင် မလိုတော့ပါဘူး။ Click တစ်ချက် နှိပ်လိုက်ရုံ ဒါမှမဟုတ် ဖုန်းနဲ့ ဓာတ်ပုံတချက်ရိုက်လိုက်ရုံနဲ့တင် Data တွေက အပြင်ကိုရောက်သွားနိုင်လို့ပါပဲ။

ဒါ့အပြင် ChatGPT တို့၊ Gemini အစရှိတဲ့ (Public AI Tools) တွေနဲ့ လုပ်ငန်းခွင်ရဲ့ Confidential Data တွေကို Upload တင်ပြီး Analysis လုပ်ခိုင်းမိလိုက်ရုံနဲ့လည်း Data Leakage က ဖြစ်သွားနိုင်လို့ပါပဲ။ (Public AI tools တွေ မကောင်းဘူးပြောတာ မဟုတ်ပါဘူး။ အကောင်းလွန်နေတာပါ)
ဒီနေရာမှာ DLP (Data Loss Prevention) ဆိုတဲ့ Security Control ရဲ့ အရေးပါမှုကိုရှင်းပြချင်ပါတယ်။ DLP System ရဲ့ အဓိက ရည်ရွယ်ချက်က Data ကို Encrypt လုပ်တာ မဟုတ်ပါဘူး။ Data ကို Backup ယူတာလည်း မဟုတ်ပါဘူး။ ဘယ် Data က Sensitive Data လဲ… ဘယ် Insider တွေက အသုံးပြုနေလဲ… ဘယ် Channel ကနေ Data တွေ leak လုပ်ဖ်ို့ ကြိုးစားနေလဲဆိုတာကို သိရှိပြီး ဒီအခြေအနေကို Control လုပ်နိုင်ဖို့ ဖြစ်ပါတယ်။

Data Leakage ဖြစ်ရတဲ့ နောက်ထပ် Hidden (Blind) Spot တွေကတော့ Camera ကနေ တလွယ်တကူ ရိုက်ယူလိုက်တဲ့ Photos တွေ နဲ့ ScreenShot (Images) ပဲ ဖြစ်ပါတယ်။ အရင်ကတော့ Document တွေ၊ Excel File တွေထဲက စာသားတွေကို Copy ကူးတာကိုပဲ DLP နဲ့ပိတ်ဖိုကြိုးစားခဲ့တာပါ။ ဒီတော့ User တွေက DLP System ကို တကွက်ပြလိုက်ပါတယ်။ Confidential Data တွေကို Clipboard ကနေ Copy ကူးပြီးထုတ်မရရင် ဖုန်းနဲ့ ဓာတ်ပုံရိုက်ပြီး ပို့မယ်ကွာ၊ Download ဆွဲလို့မရရင် Screenshot ရိုက်ပြီး ပို့တယ်ကွာ ဆိုတဲ့ နည်းလမ်းတွေကို သုံးလာကြပါတယ်။

ဒါကြောင့်ပဲ ဒီနေရာမှာ OCR (Optical Character Recognition) ဆိုတဲ့ နည်းပညာက DLP ရဲ့ စူးရှတဲ့ မျက်ဝန်းတစုံ ဖြစ်လာပါတယ်။ OCR တပ်ဆင်ထားတဲ့ Advanced DLP System တစ်ခုဟာ Image File တစ်ခုကို မြင်လိုက်တာနဲ့ ဒီအတိုင်း ကျော်မသွားတော့ပါဘူး။ ဓာတ်ပုံထဲမှာ ပါဝင်နေတဲ့ စာသားတွေ၊ Digit (ကိန်းဂဏန်းတွေ) ကို Scan ဖတ်ပြီး Text အဖြစ် ပြောင်းလဲပစ်လိုက်ပါတယ်။ အဲ့ဒီနောက်မှာမှ ဒီ Screenshot ထဲမှာ Customer ရဲ့ Credit Card နံပါတ်တွေ ပါနေလား? ဒီ ဓာတ်ပုံထဲမှာ Company ရဲ့ အရေးပါတဲ့ Source Code တွေ ပါဝင်နေလား? ဆိုတာကို Content Inspection လုပ်ပြီး တားဆီးပေးတာ ဖြစ်ပါတယ်။ ဒါကြောင့်မို့ Customer ရဲ့ Data တွေနဲ့ ငွေကြေးပိုင်းဆိုင်ရာ Information တွေကို တင်းကြပ်စွာ ထိန်းချုပ်ရတဲ့ Compliance အရေးကြီးတဲ့ Banking Sector လို နေရာမျိုးတွေမှာ ဒါဟာ အသုံးဝင်လှတဲ့ Solutions တစ်ခု ဖြစ်လာပါတယ်။

OCR က စကားလုံးတွေကို ဖတ်ပေးနိုင်တာ မှန်ပေမယ့် အဆိုပါ စာသားတွေရဲ့ နောက်ကွယ်က နောက်ခံအကြောင်းအရာ (Context) နဲ့ အသုံးပြုသူတွေ ရဲ့ရည်ရွယ်ချက် (Intent) ကိုတော့ နားမလည်နိုင်ပါဘူး။ ဥပမာ - DLP စနစ်တစ်ခုက ဝန်ထမ်းတစ်ယောက်ရဲ့ ID နံပါတ် ဒါမှမဟုတ် ဘဏ္ဍာရေး အချက်အလက် (PII Data) တွေကို Detect မိသွားတယ်ဆိုပါစို့။ သမားရိုးကျ DLP စနစ်တွေဟာ Policy ပေါ်မူတည်ပြီး Data Leakage Risk အဖြစ်သတ်မှတ်ကာ Alert သို့မဟုတ် Block ပြုလုပ်နိုင်ပါတယ်။ ဒါပေမယ့် တကယ်တမ်းမှာ Insider ဟာ သူ့ရဲ့ ကိုယ်ပိုင် လစာဖြတ်ပိုင်း (Pay Slip) ကို Upload တင်နေတာလည်း ဖြစ်နိုင်ပါတယ်။ သူ့မှာ ကုမ္ပဏီဒေတာတွေကို အပြင်ခိုးထုတ်ဖို့ မကောင်းတဲ့ ရည်ရွယ်ချက် (Actual Bad Intent) လုံးဝ မရှိပါဘူး။
ဒီလိုအမှန်တကယ် Data ခိုးယူလိုသည့် ရည်ရွယ်ချက် (Bad Intent) နဲ့ သာမာန်ပုဂ္ဂိုလ်ရေးရာ ကိစ္စရပ်များအတွက် အသုံးပြုခြင်း (Personal/Legitimate Use) တို့ကို စနစ်တကျ ခွဲခြားမပေးနိုင်ခြင်းဟာTraditional DLP Solutions အများစု ရုန်းကန်နေရတဲ့အဓိက Challenge တစ်ခုပဲဖြစ်ပါတယ်။ ဒါကြောင့် Security ရဲ့ Next Game က Data ကို Detect လုပ်နိုင်ဖို့တင်မဟုတ်တော့ဘဲ Data ရဲ့ Context နဲ့ Insider တွေရဲ့ Intent ကိုနားလည်နိုင်ဖို့ ဖြစ်လာပါတယ်။ OCR/Vision AI က စာသားကို ဖတ်နိုင်ပေမယ့် GenAI/LLM ကတော့ အဲ့ဒီ စာသားရဲ့ အဓိပ္ပာယ်, Context နဲ့ Intent ကိုပါ သုံးသပ်နိုင်ပါတယ်။ (UEBA) User Behavior ကို လေ့လာပြီး Insider Risk နဲ့ Suspicious Activity တွေကို ဖော်ထုတ်နိုင်ပါတယ်။ ဒါကြောင့် Data Protection ဟာ Keyword Matching ခေတ်ကနေ Context-Aware & Intent-Aware AI-powered Security Control တွေဆီကူးပြောင်းလာနေပြီ ဖြစ်ပါတယ်။

Security Administrator တွေဘက်က OCR Policy တွေကို သေချာ Setup မလုပ်ထားရင်ဖြစ်စေ၊ သို့မဟုတ် OCR ရဲ့ Scanning ဖတ်ရတဲ့ Process ကြောင့် User Experience မှာ နှေး (Delay) သွားတာကို ကောင်းကောင်း မကိုင်တွယ်နိုင်ရင်လည်း ဒီ Control က အလုပ်မဖြစ်ပြန်ပါဘူး။ ဒီလို Process တွေ မြန်ဆန်ဖို့အတွက် Organization တွေမှာ ခိုင်မာတဲ့ Data Classification စနစ်တစ်ခု ရှိနေဖို့က အရေးပါတဲ့ အချက်ပါပဲ။ ဘယ် Data ကတော့ High Risk, ဘယ် Data ကတော့ Low Risk, ဘယ်အရာတွေကဖြင့် Confidential ဆိုတာကို ကြိုတင်ခွဲခြားမထားဘူးဆိုရင် DLP System က လူကြီးမင်းတို့ လုပ်ငန်းခွင်ထဲက Image တိုင်း၊ File တိုင်းကို လိုက်လံ Scan ဖတ်နေရမှာဖြစ်လို့ စနစ်တစ်ခုလုံး Delay ဖြစ်ပြီး User Experience ပိုင်းမှာ နှောင့်နှေးသွားရတာ ဖြစ်ပါတယ်။
အကယ်၍ Data Classification သေချာ လုပ်ထားမယ်ဆိုရင်တော့ DLP က Inspection Scope ကိုပိုမိုကျဉ်းမြောင်းစွာ သတ်မှတ်နိုင်ပြီး OCR process ကိုပိုမိုထိရောက်မြန်ဆန်စေမှာပါ။ ဥပမာ Confidential လို့ သတ်မှတ်ထားတဲ့ Image တွေ၊ Screenshot တွေကိုပဲ Target ထားပြီး OCR နဲ့ လျင်လျင်မြန်မြန် ထိရောက်စွာ စစ်ဆေးသွားနိုင်မှာ ဖြစ်ပါတယ်။

Insider တွေအနေနဲ့လည်း ငါ ဒီData လေး တခုနှစ်ခု အပြင်ကို ပို့လိုက်ရုံနဲ့ ဘာမှမဖြစ်လောက်ပါဘူး ဆိုတဲ့ ပေါ့ဆတဲ့ Mindset နဲ့ အလေ့အထမျိုး ရှိနေသေးရင်တော့ ဘယ်လောက်ကောင်းတဲ့ System ဖြစ်စေ အသုံးဝင်မှာ မဟုတ်ပါဘူး။ ဒါဟာ DLP System ရဲ့ နည်းပညာအားနည်းချက်ကြောင့် မဟုတ်ဘဲ System ကို အသုံးပြုနေတဲ့ လူတွေရဲ့ Security Awareness ကြောင့်ပဲ ဖြစ်ပါတယ်။
Security is not a winning game ဆိုတဲ့အတိုင်း Security ဆိုတာဘောလုံးပွဲ တပွဲလို နိုင်ပွဲ/ရှုံးပွဲ သတ်မှတ်လို့ရတဲ့ Game တစ်ခု မဟုတ်ပါဘူး Cyber Security ဆိုတာက အဆက်မပြတ် သွားနေရမယ့် Process တစ်ခုဖြစ်ပြီး ဖြစ်နိုင်သမျှ Risk အနည်းဆုံးဖြစ်အောင် အကာအကွယ်ပေးရမယ့် ကာကွယ်ရေးစနစ်တစ်ခု A process and defense as much as we can to minimize the risk သာ ဖြစ်ပါတယ်။

ကိုယ့်ဘက်က ဘယ်လောက်ပဲ အဆင့်မြင့်နည်းပညာတွေ သုံးသုံး၊ Insider တွေကို ဘယ်လောက်ပဲ Security Awareness တွေ ပေးပေး၊ တာဝန်ယူမှု (Responsibility) တွေ ရှိရှိ..Human Error ကြောင့် (သို့) လိမ္မာပါးနပ်တဲ့ ခိုးယူမှု တခုခု ကြောင့် Data တွေ Leak သွားနိုင်ခြေဖြစ်တဲ့ Residual Risk အဖြစ်အမြဲတမ်း ရှိနေမှာပဲ ဖြစ်ပါတယ်။ ကိုယ်တိုင် ကြုံတွေ့ရတာမျိုး ရှိနိုင်သလို၊ ကိုယ်ရဲ့System ထဲမှာ ပြဿနာတက်လို့ တက်နေမှန်း မသိလိုက်ရတဲ့ Residual Risk တွေလည်း ရှိနေနိုင်ပါတယ်။

ဒါကြောင့် Cyber Security Team တစ်ခုအနေနဲ့ 100 Percent ပြီးပြည့်စုံတဲ့ လုံခြုံရေးကို လိုက်ရှာနေမယ့်အစား မိမိတို့ လုပ်နိုင်သမျှ အကောင်းဆုံးကို အစွမ်းကုန် လုပ်ဆောင်ပြီး (What you can do best) ဖြစ်လာနိုင်ခြေရှိတဲ့ အန္တရာယ်တွေကို စနစ်တကျ လျှော့ချကာ အဆိုပါ Residual Risk ကို အနည်းဆုံးအဆင့်ကို ရောက်အောင် ထိန်းချုပ်ထားဖို့ကသာ ပိုမိုအဓိက ကျလှပါတယ်။

အတိုချုံးပြန်ပြောရရင် Data Loss Prevention (DLP)ဆိုတာ System တစ်ခုဆိုတာထက် Organization ရဲ့ Data တွေကို Leak မဖြစ်အောင် ဘယ်လိုကာကွယ်မလဲဆိုတဲ့ Culture တစ်ခုဆို ပိုမှန်မယ်ထင်ပါတယ်။ လာမယ့် နှစ်တွေမှာလည်း Gen AI, Cloud Technology နဲ့ Hybrid Work Environment တွေဟာ အရရှိန်အဟုန်နဲ့ ပိုမိုစီးဆင်းလာမယ်ဆိုတာ လုံးဝ အသေချာပါပဲ။ ဒီလို IT ခေတ်ရေစီးကြောင်းမှာ မိမိတို့ရဲ့ Crown Jewels ဒေတာတွေကို ကာကွယ်ဖို့ OCR သာမက Context/Intent ကိုပါ နားလည်တဲ့ Advanced DLP System Security Control တွေ လိုပိုမိုလိုအပ်လာပါတယ်။

ဘယ်လောက်ကောင်းတဲ့ Technology ကိုသုံးထားသည် ဖြစ်စေ Risk ကို Zero အထိ ဖယ်ရှားနိုင်မှာ မဟုတ်ပါဘူး။ Cyber Security ရဲ့ ရည်မှန်းချက်က Perfect Security မဟုတ်ဘဲ Residual Risk ကို လက်ခံပြီး မိမိတို့ဘက်က လုပ်နိုင်သမျှ အကောင်းဆုံး (What you can do best) နဲ့ ကျန်ရှိနေမယ့် အဆိုပါ Risk ကို (Minimal Level) အနိမ့်ဆုံးအဆင့် ဖြစ်အောင် လျှော့ချထိန်းချုပ်သွားဖို့ လိုအပ်ပါကြောင်း ပြောရင်းနဲ့ DLP ပုံပြင်လေးကို ဒီမှာနားပါရစေ ခင်ဗျာ။ဖတ်ရှူမှု အတွက်လည်း ကျေးဇူးတင်ပါတယ်။

လေးစားစွာဖြင့်
မင်းကို
Senior Solutions Consultant

ATG SYSTEMS
📍 Head Office
B3, Kan Street, Kan Yeik Mon Housing,
Ward(10), Hlaing Township, Yangon.

📱 +9594477010331
📧 [email protected]