วันนี้ Workshop Azure monitoring, security, compliance ที่ มหาลัยวิทยาลัยราชภัฏบ้านสมเด็จเจ้าพระยา จัดโดยกลุ่ม Zabbix in Thailand และจัดสอนโดย อาจารย์ ตูล MVPSKILL สำหรับหัวข้อตามนี้เลยครับ
Overview
Intro Cloud [AZ-900] Short Note | naiwaen@DebuggingSoft
- Business Continuity & Disaster Recovery
Business Continuity ทำอย่างไรก็ได้ให้ธุรกิจ มันดำเนินไปต่อได้ แม้จะเจออุปสรรคต่างๆ เช่น ไฟตก / ภัยธรรมชาติ / supply chain / cyber incident / hw fail เป็นต้น
ชอบตัวอย่างที่ อจ ยกขึ้นมาดี ที่ร้านของไดัมีซ่อมร้าน 2 สัปดาห์ เจ้าของเก็บค่าเช่าอยู่ แต่ยังเปิดต่อได้นะ แม้ทำงานได้ไม่ครบ Loop หรือ ติดขัดไปบ้าง โดยการ
- แปะสติ๊กเกอร์ราคา และจดข้อมูลการขายด้วยมือ
- น้ำไม่เย็น
แต่ธุรกิจยังทำงานต่อไปได้ ขายของต่อได้ ปิดร้านก็ได้นะ แต่ค่าเช่า มันเดินไปไปนะ
- การทำให้เกิด Business Continuity ต้องทำให้เกิดความพร้อม (Readiness) จากเหตุการณ์ต่างๆ โดยปกติจะอยู่ในรูปของแผน BCP (Business Continuity Plan) เกิดอะไรขึ้นมา แล้วใครต้องมีหน้าที่อะไรบ้าง Contract Point ถ้าเอาตามมาตรฐานอย่าง ISO มีบังคับนะ
- BCP ทำมาเพื่อ
- reduce downtime
- mitigating risk + remediating issue เช่น ลด data loss / data corruption / ธุรกิจหยุดชะงักได้ กระทบรายได้ เป็นต้น - Key ของ BCDR มี 3 ส่วน ได้แก่
- Process - เวลาเกิดเคสจริงขึ้น ต้องมี Step รับมืออย่างไร
- People - ทุกคนต้องรู้หน้าที่ของตัวเอง
- Technology - เครื่องมือช่วยให้ Process + People ทำงานได้ไว สะดวกขึ้นตามแผน BC / DR
Disaster Recovery - เรียกว่าเป็น ส่วนนึงของ BCP ก็ได้ โดยจะไป focus กับงาน IT ไม่ให้ล่ม โดยจะมองว่าเป็นส่วน เพื่อช่วยให้ Business เสริมกัน
Compnent หรือ Key ของ BCP ที่ควรพิจารณา
- resilience - ผู้ใช้ / business ต้องได้รับผลกระทบน้อยที่สุด ถ้าเกิดเหตุจริงต้องอะไร พังแล้วไปใช้ อีกระบบอีก Region แต่ ผู้ใช้ / business ไม่รู้หรอกว่ามันพัง ใช้ส่วนอื่นไป
- recovery - ที่พังไป ย้ายหนีมาแล้ว เราจะกู้กับมายังไง เหมือนก่อนสภาพที่มันจะพัง ถ้ามันมีหลายส่วน เราต้องมาจัดลำดับความสำคัญ ว่าควรจะขึ้นตัวไหนก่อนหลัง
- contingency - ลำดับขั้นตอน เมื่อเกิด Issue ขึ้น
- Design Consideration
เอามาตอบว่า BCP / DR จุดไหนที่ยอมรับได้ จาก Metric
- RPO - (Recovery Point Objective ) Max Amount of Data loss ที่ยอมรับได้ กี่ Tx
- RTO - (Recovery Time Objective) Max time of System failure หรือ ที่ทำมือได้
เลขพวกนี้ Business มากำหนดนะ
- ว่าจะยอมรับได้แค่ไหน
- แยก Tier ของ App ด้วย ว่าอันไหน Tier1 / Tier2 ... จะได้คุมค่าใช้จ่ายได้
- และลงทุนแก้ปัญหาที่เกิดขึ้นได้ระดับไหน RPO / RTO มันเป็นตัวกำหนด Solution ที่ใช้เลือก ว่าจะเอา Backup / High Availability / Disaster Recovery มี Blog ผมเขียนเกี่ยวกับ RPO / RTO ด้วยนะ ลองตามกันได้
กลับที่ Cloud นอกจาก RPO / RTO จะมีตัว Service Level Agreement (SLA) ที่บอกสัญญาว่าระบบ Cloud ใช้งานได้กี่ % เช่น ใช้ Cloud 100 ชม ต้องใช้ได้ 99 ชม แสดงว่า SLA 99% โดยเราอาจจะเรียก SLA พวกนี้ว่า The 9s เช่น 99 (2 nines) / 99.9 (3 nines) / 99.99 (4 nines) / 99.999 (5 nines)
บน Azure แต่ละ Service จะมีตัว SLA แยกกันนะ VM + DB แต่ละ Service เช่น Azure VM ถ้าจะเพิ่ม SLA มี Option เพิ่ม เช่น
- Azure VM SLA 99.9%
- Azure VM + Availability Set SLA 99.95% มี 2 จุดในการตัดสินใจ
- fault domain - HW ไม่ failure พร้อมกัน อยู่คนละเครื่อง
- update domain - azure ma ไม่พร้อมกัน
ถ้าเพิ่ม fault domain + update domain เพิ่มเงิน 555 - Azure VM + Availability Zone SLA 99.99% วาง VM แยกตนละ DC
แต่ละอันมี Doc บอกจาก Service Level Agreements (SLA) for Online Service มันจะบอกของแต่ละ Service รวมถึงการคืนเงินด้วย เช่น ของ VM รายละเอียดยิบยับเลย ต้อง Download ล่าสุดมาตรวจสอบนะ เช่น Azure VM
Azure BCDR Guide
บน Azure แนวทางทำ Business Continuity Guide
- Prepare - ต้องรู้อะไรบ้าง keyword เต็มหัว Cloud / Service
- Application Continuity
1. Assess แต่ระบบ
- ว่ามี Arch แบบไหน
- มี Service Map (ยุ่งกับใครบ้าง)
- Business Impact Analysis ว่าระบบนั้นล่ม ส่งผลอย่างไร ระดับไหน H M L (ต้องนิยาม) อย่าเหมาเขย่ง แยกระบบ
- Fault tree analysis ล่มแล้วใคร ระบบไหนซวยบ้าง
- Gap Assessment
2. Implement ทำ RTO / RPO เลือก Solution ให้เหมาะสม
3. Test ทดสอบตามแผน ลอง Failover ไหม ซ้อมสักปีละครั้ง - Business Continuity - ทำให้เป็นปัจจุบัน เช่น ปีล่าสุดมีเพิ่มระบบเข้าไป ต้องมา Update doc ด้วย
Resource: https://github.com/Azure/BusinessContinuityGuide / Introducing the Azure Business Continuity Guide - Microsoft Community Hub
Azure BCDR Solution
บน Azure มี 3 ท่า ได้แก่ High Avaliability / Back Solution / Disaster Recovery
- High Availability
จากจ่ายเบาไปหนัก 555
- Availability Set - กำหนดให้ Resource กระจายไปคนละ Rack ตาม fault domain / update domain โดยมีบาง Service พวก Azure VM
- Availability Zone - อยู่คนละ Zone อันนี้หลาย Service มีเลย Azure VM / App Service / Azure SQL / AKS เป็นต้น
- Pair Region - ไปทำอีกที่เลย (Region) ถ้า region fail > ไปที่ Pair เลย
พอเพิ่มจำนวนแล้ว ต้องมีตัวที่มาจัดการ Traffic จะมีตัว
- Azure Load balancer (OSI Layer4)
- region scope
- กระจาย Traffic โดยมีแบบ External (Traffic Internet) / Internal เหมาะกับ App ที่ Stateless Note: - ถ้าเป็น Stateful พวก DB / Blob มันมี option ของมัน
Note: service ส่วนใหญ่ของ Azure ทำงานในระดับ Region - Azure Traffic Manager
- Global Scope
- DNS based เลือก region access ที่เหลือจะเป็นตัว Internal แต่ละ region แล้ว LB > App
- กำหนด Time To Live(TTL) ให้เหมาะสม
- ทำได้หลายอย่างนะ นอกจาก Solution High Availability ยังมีเรื่อง Geo-Location - DNS พวก Backend IP แต่มันอาจจะมี Cache และไม่มีกระบวนการตรวจนะ มันโยนไปใส่ IP ใน pool ตายไหม
หลังจากมี Workshop ลองทำตัว Availability Set / Availability Zone ตอนสร้าง Resource อย่างตัว VM มันจะมีให้เลือกเลยนะ ทั้ง Availability Set / Availability Zone
Workshop1: Availability Set + Manual Create Load Balance
- Create IIS + Deploy App
- Create LB มี 2 Type External (Request จาก Internet) และ Internal
- FrontEnd IP - ส่วนที่มาจากรีบ Request
- Backend IP - ส่วนของ Resource เช่น AS / AZ
Workshop2: Availability Zone + Load Balancing ทำพร้อมกันไปเลย //เสียเงินง่าย
สรุป ระหว่าง Availability Set / Availability Zone >> ควรเลือก Availability Zone นะ
จบวันแรก และต่อวันที่ 2 ตัว Azure Traffic Manager
Workshop3: Azure Traffic Manager
Sample Arch
Config Azure Traffic Manager
- กำหนด DNS สำหรับ public ip ที่ผูกกับ Load Balance หรือ VM
- สร้าง Azure Traffic Manager Profile - ตรงนี้เอากำหนด
- Rule การ Route Traffic (Rounding Method) เช่น เลือก Zone ว่าจะเอาความใกล้ (Geo Location) / Performance / Priority เป็นต้น
- Health Probe ตรงนี้ฝั่ง App ออกแบบ Path ดีนะๆ ให้เร็วๆ จะว่าไป ยังไม่ได้เขียน Blog .NET Health Check เลย 5555
- เข้าไปที่ Traffic Manager Profile ที่เพิ่งสร้าง เพิ่ม End Point เข้าไป
- การทดสอบ สามารถลองปิด VM Main Region หรือ จะลองตัว Azure Chaos Studio
- Azure Chaos Studio
- Manage Service สำหรับทำ Chaos Engineering ตอนนี้ยังใช้ได้กับาง Service VM / App Service เป็นต้น
- Chaos Engineering ทดสอบในระดับวิกฤติ เพื่อมาปรับ application + service resilience โดย
- Reproduce an incident that affected your application - ทำให้พัง แล้วดูว่า app ตอบสนองยังไง เช่น จองบัตรคอน
- Do business continuity and disaster recovery
- Run high-availability drills
- Develop application performance benchmark
- Run stress tests or load tests. - ทำเกิด Chaos จาก Azure Chaos Studio ยังไง ?
- Service-Direct - จัดการ Azure Resource เช่น reboot cluster / เพิ่ม Latency ใน Network
- Agent-Based - ลงในพวก IAAS เช่น VM มาสร้างสถานการณ์ เช่น memory เต็ม หรือ process บางอย่างถูก Kill (Required Manage Identity) - chaos experiment - ขั้นตอนการสร้างวิกฤตให้ระบบ
Workshop4: Azure Chaos Studio เอามาลองตัว Workshop3
- Chaos Studio
- Enable Resource "Service Direct"
- Enable Resource "Agent-Based" + Require Manage Identity + สิทธิในการจัดการ Resource นั้นๆ เช่น ถ้าจะลอง VM ต้องเป็น Virtual Machine Contributor ประมาณนี้
- มากำหนด Action ที่ทำได้กับ Resource นั้นๆ
- Experiment มาใส่ Scenario ของ Fault หรือ Delay
ใน Lab จะลองปิด VM มา Proof Traffic Manager Workshop 3
- จากนั้นกด Start
Note: Require Manage Identity (User Manage) + สิทธิในการจัดการ Resource นั้นๆ
- ตอนมันทำงาน ถ้าไปลองดู VM มันจะปิดให้ (Stop) แต่เงินคิดอยู่นะ
ในหัวตอนแรก สร้าง Chaos ลด Cost สัก 4-5 ชม อด 555
- Load Balance Monitor พบว่า VM Main Region ไปเรียบร้อย
- เว็บจากเข้าไม่ได้
- Traffic Manager บอกเหมือนกัน แล้วเว็บจะหายไปพักนึง แล้วจะย้ายจาก main(east asia) > secondary (east us)
- ย้ายไป Traffic Manager ย้ายไป Secondary Region (east us)
- Run เสร็จแล้ว มันจะคืนสิ่งที่แก้ไปกับ Resource
- Traffic Manager ย้ายไป Main Region (east asia) จะสุ่มเครื่อง 1 / 2 ตามตัว load balance
ถ้ามีเงินไปใช้ Paas มันทำให้หมด แก้เรื่อง ENV / Sync Code / HA ด้วย ยกตัวอย่าง App Service
- Backup Solution
เป็นอีกทางเลือกนึง สำหรับคนที่ไม่อยาก Run ระบบพร้อมกันทั้ง 2++ Site High Availability สำหรับ Backup Solution Azure
- มีตัว Recovery Service Vault
- Purpose Backup / Disaster Recovery
- For VM / SQL Server
- Feature RBAC / Secure Backup / Monitoring / Cross Region Restore / Soft Delete
- เหมือนมีเขียนใน Workshop ก่อนด้วย Azure Backup - Setup Recovery Service Vault (RSV)
- Enable immutability - ห้ามแก้ไขตามเวลาที่กำหนด
- Enable Cross Region Restore - เปิดแล้ว เปลี่ยนใจปิดทีหลังไม่ได้ มันจะช่วยให้เราเอา VM ไปขึ้นใหม่ที่ Pair Region ได้ แต่ต้องเลือก Replication Type เป็น Geo-Redudant
- Replication Type - ตัดสินใจให้เรียบร้อย ถ้ามี Data แล้วแก้ Config ไม่ได้ - Create VM
- Temp Storage (D:) ห้ามยุ่ง หายได้ตลอดเวลา
- Mount Disk ถ้ามีหลายอันทำ Software Raid 0 ได้ เพิ่มความเร็วส่ง Availability ขึ้นกับที่เลือกใน Azure
- File Share - Authenticated User เอา Everyone ออกไป
VM Backup Increment นะ จัดการโดย Automatic storage
- Config
- Enhanced Max 6 ครั้ง/วัน
- Standard
>> Instant restore Retain instant recovery snapshot(s) for เป็นได้กี่วัน ถ้าเกินจากนั้นจะเอามา Restore Full VM ไม่ได้ ถ้าเกินจะได้เฉพาะไฟล์และ
>> Retention range เก็บไว้นานเท่าไหร่ Daily / Weekly / Monthly / Yearly
Note: manual backup default retain 1 เดือน
Recovery points
- Crash Consistent - ใช้ตอน Disaster Recovery
- Application Consistent - ดีสุด ใช้ตัว VSS Provider
เช่น SQL > VSS Provider (Shadow Copy) > Disk
พวก SW Backup จะมาคุยกับ VSS Provider - File System Consistent - แย่สุด
Ref: About Azure VM backup - Azure Backup | Microsoft Learn
Workshop5: Azure Backup + Restore VM (Full Restore)
- Create Recovery Service Vault
- Set Backup Policy
- Backup
- Azure Resource > Backup > Restore VM
- ตอนเลือก Restore Point
ตามวันที่กำหนดจาก Instant restore Retain instant recovery snapshot(s) for
ถ้าตั้ง 2 วัน แสดงว่าเรา Restore แบบตั้ง VM ใหม่ได้ ถอยจากวันที่เกิดปัญหาได้ 2 ตัว
- Required Storage Account เอาเป็น Temp ก่อนที่จะสร้าง VM ใหม่แยก / Create VM ทับของเดิม
Workshop6: Azure Backup + File Restore
เคสที่เพิ่งรู้ว่าไฟล์หายไป เกินจากช่วง Retain instant recovery ไปแล้ว
- Azure Resource > Backup > File Recovery
- เลือก Restore Point กด Download Script
ให้มัน Generate Script สักพัก Download + Copy Password
- Remote ไป VM ที่เปิดปัญหา เอา Script PowerShell ที่ Generate ไปวาง รอ Run Script มันจะทำหน้าที่ Mount Disk ก้อนใหม่
- ให้เรา Copy ไฟล์ที่หายมา
- ไปที่ Azure Portal > Unmount Disks หรือ รอ 12 ชั่วโมง เดียวมันจะหลุดเอง //ถ้าไฟล์ใหญ่ต้องวางแผน
ถ้าใช้ Windows Server ไปเปิด Shadows Copies + ตั้ง Schedule และให้ End Users ไปใช้ Feature Previous Version แทนได้นะ //Windows 10 / 11 ก็มี วันนี้เพิ่งรู้ว่ามันทำอะไรนี่แหละ 555
- Disaster Recovery
มันต่อยอดมาจาก Backup 2 แบบ
Cross Region Restore
- ระบบตายก่อน แล้วค่อยเอา Backup Restore บน Pair Region ยอมรับ Downtime ได้เยอะ
- ตอนที่สร้าง RSV ต้องเลือก
- Backup Storage Redundancy Geo-Redundant
- Cross Region Restore Enable - ตอนใช้งานจริงมี Secondary Region ให้เลือก เรากด Restore ได้เลย
Azure Site Recovery
- Replicate ข้อมูลไปย้ายไปปลายทาง
- ตอนที่มีปัญหาเรากดได้เลย
Workshop7: Azure Site Recovery อันนี้กดมาถึงเท่านี้ ไม่กล้ากดต่อ ต้องรอ Sync กินเงิน 555
ดูต่อเหมือนจะไม่มี Sand Box แต่มี MS Learn
- Tutorial to run an Azure VM disaster recovery drill with Azure Site Recovery - Azure Site Recovery | Microsoft Learn
- Introduction to Azure Site Recovery - Training | Microsoft Learn
Note
- ถ้ามี Resource เยอะๆ Azure มีตัว Azure Business Continuity Center ดูจาก Protected Items หรืออันไหนลืมได้เลย
Reference
- Business Continuity Planning and Disaster Recovery for Azure Workload | Facebook
- Azure/BusinessContinuityGuide: A BCDR guide for Microsoft Azure customers (github.com)
Discover more from naiwaen@DebuggingSoft
Subscribe to get the latest posts sent to your email.