# MediationZone ทำงานอย่างไร — เจาะที่ Control Zone และ Execution Zone บันทึกจากการใช้งานและตรวจสอบเครื่องจริง · อ้างอิง DigitalRoute MediationZone 9.3.1.3 บน RHEL 9 · ปรับปรุง 3 พฤศจิกายน 2569 > เอกสารนี้ครอบคลุมเฉพาะ **CZ (Control Zone)** และ **EX (Execution Zone)** ไม่รวมเครื่อง Back-end > ค่าตัวเลขและชื่อทั้งหมดมาจากระบบจริง และระบุกำกับไว้ว่ามาจากสภาพแวดล้อมใด --- ## 1. MediationZone คืออะไร ระบบตัวกลางแลกเปลี่ยนและแปลงข้อมูลระหว่างระบบงาน หน้าที่หลักคือ **รับข้อมูลเข้า → แปลง → ส่งออก** ตามกติกาที่ออกแบบไว้ใน workflow สิ่งที่ต้องเข้าใจก่อนอย่างอื่น — MediationZone **ไม่ได้เป็นโปรแกรมตัวเดียว** แต่เป็นกลุ่มของ process ที่เรียกว่า **pico** กระจายอยู่หลายเครื่อง แล้วทำงานร่วมกันเป็นระบบเดียว --- ## 2. pico และ container — หน่วยพื้นฐานที่ต้องเข้าใจก่อน ```mermaid flowchart TB subgraph HOST["เครื่องหนึ่งเครื่อง"] direction TB CONT["container
หน่วยการตั้งค่าของเครื่องนี้
เช่น cz หรือ cz1"] CONT --> P1["pico: platform"] CONT --> P2["pico: ui"] end NOTE["pico = process หนึ่งตัวที่มีหน้าที่ของมัน
container = ชื่อเรียกชุดตั้งค่าของเครื่องนั้น"] ``` | คำ | ความหมาย | |---|---| | **pico** | process หนึ่งตัวที่รับผิดชอบงานอย่างหนึ่ง เช่น `platform`, `ui`, `ecsa1` | | **container** | ชื่อของชุดการตั้งค่าประจำเครื่อง ใช้อ้างอิงเวลาแก้ property ผ่าน `topo` | | **MZ_HOME** | ที่อยู่ของระบบทั้งหมด — ในที่นี้คือ `/mz/mzapp` | **กับดักที่พบบ่อย** — ชื่อ container **ไม่เหมือนกันทุกเครื่อง** และถ้าใส่ผิดชื่อ คำสั่ง `topo get` จะตอบ `"data": null` เฉย ๆ **โดยไม่มี error** ทำให้เข้าใจผิดว่าค่านั้นไม่มี จึงต้องหาชื่อจริงด้วย `mzsh topo container` ทุกครั้งก่อนใช้งาน --- ## 3. สามโซนตามสถาปัตยกรรมที่ผู้ผลิตออกแบบไว้ ```mermaid flowchart TB subgraph AZ["Access Zone — ทางเข้าของคน"] DT["Desktop
โปรแกรมบนเครื่องผู้ดูแล"] WEB["Web UI"] end subgraph CZ["Control Zone — สมองของระบบ"] PF["pico: platform"] UIP["pico: ui"] DB[("ฐานข้อมูล
config · log · สถิติ")] end subgraph EZ["Execution Zone — แรงงานของระบบ"] E1["pico: ecsa1"] E2["pico: ecsa2"] E3["pico: ecsa3"] E4["pico: ecsa4"] end DT --> UIP WEB --> UIP UIP --> PF PF <--> DB PF <-->|"ขึ้นทะเบียน · รับคำสั่ง · ส่งสถานะ"| E1 PF <--> E2 PF <--> E3 PF <--> E4 E1 --> EXT[("ระบบต้นทาง / ปลายทาง")] E2 --> EXT E3 --> EXT E4 --> EXT ``` | โซน | ทำอะไร | อยู่บนเครื่องไหน | |---|---|---| | **Access Zone** | ทางเข้าสำหรับผู้ดูแล — ออกแบบ workflow, ดูสถานะ, จัดการผู้ใช้ | เครื่องของผู้ใช้ ไม่ใช่เซิร์ฟเวอร์ | | **Control Zone** | ควบคุมทุกอย่าง เก็บ config เก็บ log แจก code สั่งงาน | เครื่อง **CZ** | | **Execution Zone** | รัน workflow จริง ประมวลผลข้อมูลจริง | เครื่อง **EX** | **ข้อมูลธุรกิจไม่ได้ไหลผ่าน Control Zone** — ข้อมูลวิ่งเข้าออกที่ Execution Zone โดยตรง Control Zone คุมแต่คำสั่งและสถานะ --- ## 4. Control Zone — เครื่อง CZ ทำอะไรบ้าง CZ รัน pico 2 ตัว | pico | หน้าที่ | |---|---| | **`platform`** | สมองของทั้งระบบ ภายในมีบริการย่อยหลายตัวรวมอยู่ใน process เดียว | | **`ui`** | ให้ Desktop และ Web UI ต่อเข้ามา | ### บริการย่อยที่อยู่ภายใน pico `platform` ```mermaid flowchart TB PF["pico: platform"] --> WS["Workflow Server
สั่งเริ่ม หยุด กระจาย workflow"] PF --> CS["Code Server
แจก code ให้ pico ทุกตัว"] PF --> GS["Group Server
จัดการ workflow group"] PF --> AM["Activation Manager"] PF --> RM["Reference Manager"] PF --> AL["Audit Log"] PF --> ES["Event Server"] PF --> SL["System Log"] PF --> ALM["Alarm Manager"] PF --> NS["Notification Server"] PF --> SM["Statistics Manager"] PF --> MU["Management Utilities"] ``` **ตัวที่สำคัญที่สุดต่อการเปิดปิดระบบคือ Code Server** เพราะ > **pico ทุกตัวต้องดาวน์โหลด code จาก Code Server ตอนสตาร์ต** ซึ่งแปลว่า **ถ้า `platform` ไม่ทำงาน pico ตัวอื่นสตาร์ตไม่ได้เลย** ไม่ใช่แค่สั่งงานไม่ได้ — นี่คือเหตุผลที่ลำดับการเปิดระบบห้ามสลับ ### ช่องทางที่ CZ เปิดไว้ ```mermaid flowchart LR CLI["mzsh · mzcli"] -->|"9000 · HTTP"| PORT9000["mz.wi.port"] EC["pico ecsaN"] -->|"9000 ตอนสตาร์ต
ขอ code และ topology"| PORT9000 EC2["pico ecsaN"] -->|"6790 · binary
ตอนทำงาน"| PORT6790["pico.rcp.platform.port"] DESK["Desktop"] -->|"9001"| PORT9001["pico ui"] PORT9000 --> PFP["process: platform"] PORT6790 --> PFP PORT9001 --> UIP2["process: ui"] ``` | port | ชื่อในระบบ | โปรโตคอล | ใช้ทำอะไร | |---|---|---|---| | **9000** | `mz.wi.port` | HTTP | ช่องทางบริหารจัดการ — รับคำสั่งจาก `mzsh`/`mzcli`, แจก topology และ code ให้ pico | | **6790** | `pico.rcp.platform.port` | binary | ช่องทาง runtime — pico เรียก platform ระหว่างทำงาน | | **9001** | ของ pico `ui` | HTTP | หน้าจอผู้ดูแล | **9000 กับ 6790 เปิดโดย process เดียวกัน** คือ `platform` ตรวจด้วย `ss -lntp` จะเห็น pid เดียวกัน **ข้อสำคัญตอนเปิดระบบ** — ต้องรอให้ **port 6790 พร้อมก่อน** จึงค่อยเปิด `ui` ไม่อย่างนั้น `ui` จะเปิดไม่ขึ้นเพราะต่อ platform ไม่ติด --- ## 5. Execution Zone — เครื่อง EX ทำอะไร EX รัน pico ชื่อ `ecsa1` `ecsa2` ... ซึ่งคือ **Execution Container** ตัวที่รัน workflow จริง ```mermaid flowchart TB subgraph EX1["เครื่อง EX01"] EC1["pico: ecsa1"] EC1 --> W1["workflow กลุ่มที่ 1"] end subgraph EX2["เครื่อง EX02"] EC2["pico: ecsa2"] EC2 --> W2["workflow กลุ่มที่ 2"] end subgraph EX3["เครื่อง EX03"] EC3["pico: ecsa3"] EC3 --> W3["workflow กลุ่มที่ 3"] end subgraph EX4["เครื่อง EX04"] EC4["pico: ecsa4"] EC4 --> W4["workflow กลุ่มที่ 4"] end PF2["platform บน CZ"] --> EC1 PF2 --> EC2 PF2 --> EC3 PF2 --> EC4 ``` **การกระจายงาน** — workflow ถูกแบ่งให้ EC แต่ละตัว ไม่ได้รันซ้ำกัน ดังนั้น - **EX หลายเครื่องคือการกระจายภาระ ไม่ใช่การสำรองแบบ active-standby** ถ้าเครื่องหนึ่งหยุด workflow ชุดของเครื่องนั้นก็หยุดไปด้วย ไม่มีใครรับช่วงให้อัตโนมัติ - การอัพเกรดจึงต้องทำ **ทีละเครื่อง** และต้องย้ายภาระออกจากเครื่องที่กำลังทำก่อน เช่นใช้ load balancer กันทราฟฟิกไม่ให้วิ่งเข้าเครื่องนั้น --- ## 6. ลำดับตอน pico สตาร์ต — ทำไมถึงต้องมี platform ก่อน ```mermaid flowchart TB S1["สั่งสตาร์ต pico ecsaN"] --> S2["ติดต่อ platform ที่ port 9000"] S2 --> Q1{"platform ตอบไหม"} Q1 -->|"ไม่ตอบ"| F1["สตาร์ตไม่ได้
จบ"] Q1 -->|"ตอบ"| S3["ดาวน์โหลด topology และ config"] S3 --> S4["ดาวน์โหลด code จาก Code Server"] S4 --> S5["ขึ้นทะเบียนตัวเองกับ platform"] S5 --> S6["เปิดช่อง runtime ที่ port 6790"] S6 --> S7["พร้อมรับคำสั่งให้รัน workflow"] ``` จาก flow นี้จะเห็นว่า **platform เป็นเงื่อนไขของการเกิดขึ้นของ pico อื่นทั้งหมด** ไม่ใช่แค่ผู้สั่งงาน --- ## 7. เรื่องสำคัญที่สุด — เมื่อ EC ขาดการติดต่อกับ platform เอกสารของผู้ผลิตระบุไว้ตรง ๆ ว่า > **An EC will stop execution if the connection with the Platform is lost** ```mermaid flowchart TB A["EC ขาดการติดต่อกับ platform"] --> Q{"workflow ตัวนี้ตั้งเป็น standalone ไว้ไหม"} Q -->|"ไม่ได้ตั้ง
ค่าปกติ"| B["workflow ถูก abort"] Q -->|"ตั้งไว้
เฉพาะ real-time"| C["ทำงานต่อได้
เก็บงานค้างลง ec.backlog.dir"] B --> D["ข้อมูลค้างที่ระบบต้นทาง"] A --> E["ผ่านไป 45 นาที"] E --> F["platform ถอนทะเบียน EC
และบันทึกว่า workflow ถูก abort"] F --> G["แต่ process จริงอาจยังค้างอยู่บนเครื่อง
สถานะในระบบกับความจริงไม่ตรงกัน"] ``` **สิ่งที่ต้องจำให้ขึ้นใจ** 1. **ค่าตั้งต้นคือ abort** ไม่ใช่ทำงานต่อ · workflow ที่จะรอดต้องเป็น real-time และถูกตั้ง standalone ไว้โดยเจตนาเท่านั้น 2. **45 นาที** คือเส้นตายที่ platform จะถอนทะเบียน EC ทิ้ง 3. หลังถอนทะเบียนแล้ว **สถานะที่ระบบรายงานกับสิ่งที่เกิดขึ้นจริงอาจไม่ตรงกัน** ต้องตรวจที่เครื่องจริงด้วย **ผลต่อการวางแผนงาน** — การ `restart platform` ไม่ใช่เรื่องเล็ก ที่ระบบ production ต้องจัดช่วงเวลาเสมอ ไม่ใช่ทำสด ๆ ได้ --- ## 8. workflow และ workflow group — ลำดับที่ห้ามสลับ ```mermaid flowchart TB subgraph STOP["ตอนหยุด — ไล่จากนอกเข้าใน"] direction TB T1["1. บันทึกรายชื่อ workflow ที่ทำงานอยู่
*** ขั้นบังคับ ห้ามข้าม ***"] T1 --> T2["2. ปิดการใช้งาน workflow group"] T2 --> T3["3. ปิดการใช้งาน workflow รายตัว"] T3 --> T4["4. สั่งหยุด workflow"] T4 --> T5["5. ปิด pico ecsaN"] end subgraph START["ตอนคืนค่า — ไล่กลับทาง"] direction TB R1["1. เปิด pico ecsaN"] R1 --> R2["2. เปิดการใช้งาน workflow group"] R2 --> R3["3. เปิดการใช้งาน workflow รายตัว"] R3 --> R4["4. สั่งเริ่มทำงาน"] R4 --> R5["5. นับจำนวนให้ครบตามที่บันทึกไว้"] end ``` **เหตุผลที่ต้องปิดการใช้งานก่อนสั่งหยุด** — ถ้าสั่งหยุดโดยที่ยังเปิดการใช้งานอยู่ ตัวจัดตารางอาจสั่งให้มันกลับมาทำงานเองระหว่างที่เรากำลังทำงานอื่น **เหตุผลที่ต้องบันทึกรายชื่อก่อนเสมอ** — ไม่มีคำสั่ง "คืนค่าทั้งหมดกลับเหมือนเดิม" ถ้าไม่ได้จดไว้ว่าก่อนหน้านี้ตัวไหนเปิดตัวไหนปิด จะคืนค่าไม่ถูก --- ## 9. ลำดับเปิดปิดทั้งระบบ ```mermaid flowchart LR subgraph SD["ปิดระบบ"] direction TB D1["workflow ทั้งหมด"] --> D2["ecsa4 → ecsa3 → ecsa2 → ecsa1"] D2 --> D3["ui"] D3 --> D4["platform
*** ปิดท้ายสุด ***"] end subgraph SU["เปิดระบบ"] direction TB U1["platform
*** เปิดก่อนเพื่อน ***"] --> U2["รอจน port 6790 พร้อม"] U2 --> U3["ui"] U3 --> U4["ecsa1 → ecsa2 → ecsa3 → ecsa4"] U4 --> U5["คืนค่า workflow"] end ``` **กฎง่าย ๆ ที่จำได้ทันที** — `platform` **ปิดท้ายสุด เปิดก่อนเพื่อน** เพราะทุกคนต้องพึ่งมัน --- ## 10. การทำ HA ที่ Control Zone และช่องว่างที่ต้องรู้ ที่ศูนย์ข้อมูลหลัก CZ ทำเป็นคู่ โดยใช้ Veritas InfoScale จัดการดิสก์และ VIP ```mermaid flowchart TB subgraph CL["VCS Cluster"] direction LR C1["CZ01
ถือ service group อยู่"] C2["CZ02
สำรอง"] C1 <-->|"heartbeat"| C2 end C1 -->|"mount อยู่"| FS[("/mz/mzapp
บน VxFS")] C2 -.->|"มองเห็นแต่ไม่ได้ถือ"| FS VIP["VIP — ปลายทางของ MZ_PLATFORM"] --> C1 EXN["pico ecsa1-4 บนเครื่อง EX"] -->|"ชี้มาที่ VIP ไม่ใช่ IP ของเครื่อง"| VIP ``` **จุดที่ออกแบบไว้ดี** — `MZ_PLATFORM` ของทุกเครื่องชี้ไปที่ **VIP** ไม่ได้ชี้ไปที่ IP จริงของ CZ01 ดังนั้นเมื่องานย้ายไป CZ02 เครื่อง EX ทุกตัวยังหาเจอโดยไม่ต้องแก้ config เลย **ช่องว่างที่ต้องรู้** — ใน cluster **ไม่มี resource ของ MediationZone** ```mermaid flowchart TB EV["service group ย้ายไป CZ02"] --> R1["VCS: import disk group"] R1 --> R2["VCS: mount /mz/mzapp"] R2 --> R3["VCS: ผูก VIP"] R3 --> STOP2["VCS จบหน้าที่ตรงนี้"] STOP2 --> Q{"ใครสั่งเปิด platform"} Q -->|"ไม่มีใคร"| BAD["ระบบยังไม่กลับมา
ถึงแม้ดิสก์และ IP พร้อมแล้ว"] Q -->|"สคริปต์ที่เขียนเอง"| GOOD["สั่ง mzsh startup platform
ระบบกลับมาคุมได้"] ``` **สรุปคือ failover ของ VCS ไม่ใช่ failover ของ MediationZone** — VCS ยกของให้พร้อมเท่านั้น ต้องมีสคริปต์ภายนอกคอยเฝ้าว่า service group ย้ายมาแล้วหรือยัง แล้วสั่งเปิด `platform` เอง --- ## 11. ค่าจริงจากระบบที่อ้างอิง | รายการ | ศูนย์ข้อมูลหลัก (DC) | ศูนย์สำรอง (DR) | DEV | |---|---|---|---| | เครื่อง CZ | CZ01 และ CZ02 เป็นคู่ cluster | 1 เครื่อง ไม่ได้ใช้ cluster จริง | 1 เครื่อง | | เครื่อง EX | 4 เครื่อง `ecsa1`–`ecsa4` | 4 เครื่อง `ecsa1`–`ecsa4` | – | | `MZ_PLATFORM` | `http://172.29.112.100:9000` — **เป็น VIP** | – | `http://172.29.212.18:9000` — IP จริงของเครื่อง | | ชื่อ container ของ CZ | `cz` | – | `cz1` | | workflow | ต้องสำรวจและบันทึกก่อนทำงานทุกครั้ง | **236 ตัว · 8 group** (`ecsa1`–`ecsa4` ละ 59) | – | | `MZ_HOME` | `/mz/mzapp` อยู่บน VxFS ที่ cluster ถือ | `/mz/mzapp` บน xfs ธรรมดา | `/mz/mzapp` | --- ## 12. กฎเรื่องสิทธิ์ — เรื่องที่พลาดแล้วแก้ยาก ```mermaid flowchart TB CMD["คำสั่ง mzsh · mzcli · topo"] --> Q{"รันด้วย user อะไร"} Q -->|"mzadmin
เจ้าของ MZ_HOME"| OK["ถูกต้อง"] Q -->|"root"| BAD2["ไฟล์เปลี่ยนเจ้าของเป็น root
ระบบพังในภายหลัง
หาสาเหตุยากมาก"] ``` > คำสั่งของ MediationZone **ต้องรันด้วย OS user ที่เป็นเจ้าของ `MZ_HOME` เท่านั้น ห้ามใช้ root เด็ดขาด** ตรวจว่ามีไฟล์ที่เจ้าของผิดหรือไม่ ```bash find /mz/mzapp -user root # ต้องได้ผลเป็น 0 ไฟล์ ``` --- ## 13. คำสั่งที่ใช้บ่อย ```bash # ----- อ่านอย่างเดียว ปลอดภัย ----- mzsh status # pico ตัวไหนทำงานอยู่ mzsh topo container # ชื่อ container จริงของเครื่องนี้ — หาก่อนใช้ topo เสมอ mzsh topo get topo://container:<ชื่อ>/pico:platform/val: ss -lntp | grep -E '9000|6790|9001' grep -n MZ_PLATFORM $MZ_HOME/bin/mzsh find /mz/mzapp -user root # ----- เปิดปิด pico — ลำดับสำคัญ ----- mzsh startup platform # เปิดก่อนเพื่อนเสมอ mzsh startup ui # รอ 6790 พร้อมก่อน mzsh startup ecsa1 # แล้วค่อยไล่ ecsa1 → ecsa4 mzsh shutdown ecsa4 # ตอนปิด ไล่กลับทาง ecsa4 → ecsa1 mzsh shutdown ui mzsh shutdown platform # ปิดท้ายสุด # ----- จัดการบัญชีผู้ใช้ ----- export MZCLI_HOST= MZCLI_PORT=9000 MZCLI_USER='<บัญชี>' read -rs MZCLI_PASSWORD; export MZCLI_PASSWORD # ไม่ให้รหัสติด history และไม่โผล่ใน ps mzcli user # ดูคำสั่งที่รองรับ มีแค่ enable และ disable mzcli user enable <ชื่อบัญชี> # ----- ระวังเป็นพิเศษที่ระบบ production ----- # mzsh restart platform <-- EC ขาดการติดต่อ workflow ที่ไม่ได้ตั้ง standalone จะ abort ``` --- ## 14. กับดักที่เจอจริง | กับดัก | อาการ | ทางแก้ | |---|---|---| | เปิด `ui` ก่อน port 6790 พร้อม | `ui` เปิดไม่ขึ้น | รอ 6790 ก่อนเสมอ | | ชื่อ container ผิด | `topo get` ตอบ `"data": null` **ไม่มี error** เข้าใจผิดว่าไม่มีค่านั้น | หาด้วย `mzsh topo container` ทุกครั้ง | | รันคำสั่งด้วย root | ไฟล์เปลี่ยนเจ้าของ ระบบพังทีหลัง | ใช้ OS user เจ้าของ `MZ_HOME` เท่านั้น | | คิดว่า failover ของ cluster = ระบบกลับมา | ดิสก์กับ IP พร้อมแต่ไม่มีใครเปิด `platform` | ต้องมีสคริปต์สั่งเปิดเอง | | สั่งหยุด workflow โดยไม่ปิดการใช้งานก่อน | ตัวจัดตารางสั่งให้กลับมาทำงานเองระหว่างทำงานอื่น | ปิดการใช้งานก่อนสั่งหยุดเสมอ | | ไม่ได้บันทึกรายชื่อ workflow ก่อนหยุด | คืนค่ากลับไม่ครบ ไม่รู้ว่าเดิมตัวไหนเปิดอยู่ | บันทึกเป็นขั้นบังคับ | | `systemimport` | import ผู้ใช้เข้ามาในสภาพ **ปิดการใช้งานทั้งหมด** ล็อกอินไม่ได้โดยไม่มีใครตั้งใจ | ตรวจช่อง Enable ของบัญชีสำคัญหลัง import ทุกครั้ง | --- ## 15. สรุปสิ่งที่ควรจำ 1. **MediationZone คือกลุ่มของ pico** ไม่ใช่โปรแกรมตัวเดียว 2. **CZ คือสมอง · EX คือแรงงาน** ข้อมูลธุรกิจไม่ได้ไหลผ่าน CZ 3. **pico ทุกตัวต้องโหลด code จาก platform ตอนสตาร์ต** ดังนั้น platform เปิดก่อนเพื่อน ปิดท้ายสุด 4. **port 9000 คุมจัดการ · 6790 คือ runtime** และเป็น process เดียวกัน 5. **EC ขาดการติดต่อกับ platform แล้ว workflow จะ abort** ไม่ใช่ทำงานต่อ และถูกถอนทะเบียนใน 45 นาที 6. **EX หลายเครื่องคือกระจายภาระ ไม่ใช่สำรองให้กัน** เครื่องไหนหยุด งานของเครื่องนั้นหยุด 7. **`MZ_PLATFORM` ชี้ที่ VIP** คือสิ่งที่ทำให้ย้าย CZ ได้โดยไม่ต้องแก้ config ที่ EX 8. **VCS ยกดิสก์ให้เสร็จแล้วจบ** การเปิด MediationZone กลับเป็นคนละเรื่อง ต้องจัดการเอง

SECURE_ACCESS

DOWNLOAD_LOCKED

MediationZone ทำงานอย่างไร

CONFIRM_DELETE