# Veritas InfoScale ทำงานอย่างไร — ฉบับเข้าใจกลไก บันทึกจากการใช้งานและตรวจสอบเครื่องจริง · อ้างอิง InfoScale 8.0.2 บน RHEL 9 · ปรับปรุง 3 พฤศจิกายน 2569 > ตัวเลขและชื่อทั้งหมดในเอกสารนี้มาจาก cluster ที่ตรวจสอบจริง ไม่ได้ยกมาจากคู่มือ --- ## 1. InfoScale คืออะไร และที่สำคัญกว่าคือ "ไม่ใช่" อะไร **ไม่ใช่** สถาปัตยกรรมแบบ agent-server — ไม่มีเซิร์ฟเวอร์กลางคอยสั่งการ ไม่มี master ไม่มี controller InfoScale คือชุดซอฟต์แวร์ที่ติดตั้ง **ครบทั้งก้อนเหมือนกันทุกเครื่อง** แล้วเครื่องเหล่านั้นคุยกันเองแบบ **peer-to-peer** เพื่อตกลงว่าใครจะเป็นคนถือทรัพยากร ณ เวลาหนึ่ง ความเข้าใจผิดที่พบบ่อย | เข้าใจว่า | ความจริง | |---|---| | มีเซิร์ฟเวอร์ InfoScale คอยคุม node | ไม่มี · ทุก node เท่าเทียมกัน ตัดสินใจร่วมกัน | | agent บนเครื่องรายงานไปหาส่วนกลาง | agent คือโปรแกรมเล็ก ๆ บนเครื่องเดียวกัน ถูกสั่งโดย daemon ของเครื่องนั้นเอง | | config เก็บที่ส่วนกลาง | `main.cf` เป็นสำเนาที่เหมือนกันเป๊ะบนทุก node | | VIOM คือตัวควบคุม | VIOM เป็นแค่หน้าจอไว้ดู ไม่มีมัน cluster ก็ทำงานปกติ | --- ## 2. ภาพรวมสถาปัตยกรรม ```mermaid flowchart TB subgraph NODE1["NODE 1 — ถือ service group อยู่"] direction TB H1["had
คุม cluster"] A1["agent: DiskGroup Volume Mount IP NIC"] V1["vxconfigd
คุม disk group"] K1["kernel module
vxio vxdmp vxfs"] H1 --> A1 A1 --> V1 V1 --> K1 end subgraph NODE2["NODE 2 — สำรอง พร้อมรับงาน"] direction TB H2["had
คุม cluster"] A2["agent: ชุดเดียวกันเป๊ะ"] V2["vxconfigd"] K2["kernel module
ชุดเดียวกันเป๊ะ"] H2 --> A2 A2 --> V2 V2 --> K2 end H1 <-->|"LLT / GAB
heartbeat 2 เส้น"| H2 K1 -->|"import อยู่
เขียนอ่านได้"| DISK[("Shared Disk
DATA_DG")] K2 -.->|"มองเห็นแต่ไม่ได้ import"| DISK ``` **หัวใจอยู่ที่เส้นประ** — NODE 2 มองเห็นดิสก์ก้อนเดียวกันตลอดเวลา แต่ไม่ได้ import ไว้ การมีเพียงเครื่องเดียวที่ import คือสิ่งเดียวที่กันไม่ให้ข้อมูลพัง --- ## 3. ชั้นของซอฟต์แวร์ — แยกให้ออกระหว่าง kernel กับ userspace เรื่องนี้สำคัญมากตอนอัพเกรด เพราะของสองชั้นนี้อัพคนละแบบและพังคนละอาการ ```mermaid flowchart TB subgraph US["userspace — โปรแกรมธรรมดา"] HAD["had · hashadow
สมองของ cluster"] AG["resource agent
มือและเท้า"] VXC["vxconfigd
สมองของ volume manager"] end subgraph KS["kernel space — module ผูกกับเวอร์ชัน kernel"] LLT["llt — ส่งแพ็กเก็ต heartbeat"] GAB["gab — สมาชิกภาพของกลุ่ม"] AMF["amf — แจ้งเตือนเมื่อ resource เปลี่ยนสถานะ"] VXIO["vxio — volume manager"] VXDMP["vxdmp — multipathing"] VXFS["vxfs — filesystem"] end HAD --> GAB AG --> AMF VXC --> VXIO VXIO --> VXDMP VXFS --> VXIO GAB --> LLT VXDMP --> HW[("ดิสก์จริง / SAN")] ``` **จุดเจ็บปวดที่สุดของผลิตภัณฑ์นี้** — module ในกรอบล่างผูกกับเวอร์ชัน kernel โดยตรง ถ้าอัพ OS แล้ว kernel เปลี่ยน แต่ InfoScale ยังเป็นรุ่นเดิมที่ไม่มี module สำหรับ kernel ใหม่ **module จะโหลดไม่ขึ้น** ผลคือ - `vxio` ไม่ขึ้น → ไม่มี volume → ไม่มี filesystem → เครื่องอาจบูตขึ้นมาในสภาพใช้งานไม่ได้ - `llt` `gab` ไม่ขึ้น → form cluster ไม่ได้ → service group ขึ้นไม่ได้ นี่คือเหตุผลที่ลำดับการอัพเกรดต้องระวังมาก ดูหัวข้อ 11 --- ## 4. ชั้นสื่อสาร — LLT, GAB, AMF ```mermaid flowchart LR APP["had และ module อื่น ๆ"] --> GAB2["GAB
Group Atomic Broadcast"] GAB2 --> LLT2["LLT
Low Latency Transport"] LLT2 --> NIC1["ens36"] LLT2 --> NIC2["ens37"] LLT2 -.->|"เส้นสำรอง"| NIC3["ens33 — เส้นสาธารณะ"] ``` **LLT** ส่งข้อมูลระหว่าง node โดยไม่ผ่าน TCP/IP — คุยกันที่ระดับ Ethernet เพื่อความเร็วและเพื่อไม่ให้ปัญหาของ IP stack มากระทบ heartbeat · ต้องมีอย่างน้อย 2 เส้นแยกกันทางกายภาพ ไม่งั้นสายเส้นเดียวขาดแล้ว cluster เข้าใจว่าอีกฝั่งตาย **GAB** สร้างแนวคิด "สมาชิกของกลุ่ม" ขึ้นมาบน LLT และรับประกันว่าข้อความถึงทุกคนหรือไม่ถึงใครเลย · GAB แบ่งเป็น **port** โดยแต่ละ port คือหนึ่งบริการ | GAB port | ใครใช้ | มีใน cluster ที่ตรวจ | |---|---|---| | `a` | GAB เอง — สมาชิกภาพพื้นฐาน | ✅ | | `b` | **I/O fencing** | ❌ **ไม่มี = ไม่ได้เปิด fencing** | | `h` | VCS `had` | ✅ | | `f` `u` `v` `w` | CFS / CVM สำหรับ cluster filesystem | ไม่ได้ใช้ | อ่านด้วย `gabconfig -a` — ผลจากเครื่องจริง ``` Port a gen a6c001 membership 01 Port h gen a6c004 membership 01 ``` `membership 01` แปลว่า node หมายเลข 0 และ 1 อยู่ครบ · **การไม่มี port b คือสิ่งที่ต้องรู้ให้ได้ตั้งแต่วันแรก** เพราะแปลว่าไม่มีกลไกใดกันการ import พร้อมกัน **AMF** คือ module ที่ทำให้ agent รู้ทันทีเมื่อ resource เปลี่ยนสถานะ แทนที่จะต้องวนถามทุก ๆ 60 วินาที ช่วยให้ตรวจจับได้เร็วและกิน CPU น้อยลง --- ## 5. VxVM — ชั้นจัดการดิสก์ ```mermaid flowchart TB LUN[("LUN จาก SAN
3PAR · 50 GB")] --> DISK["cdsdisk
3pardata0_392"] DISK --> DM["disk media
ชื่อในกลุ่ม: disk1"] DM --> DG["Disk Group
DATA_DG · version 320"] DG --> VOL["Volume
DATA_VOL"] VOL --> FS["VxFS filesystem
mount ที่ /MZAPP_MNT"] ``` **แนวคิดที่ต้องเข้าใจ** - **cdsdisk** = Cross-platform Data Sharing format · เป็นรูปแบบ label ที่ทำให้ดิสก์ย้ายข้ามเครื่องและข้ามแพลตฟอร์มได้ · เป็นสิ่งที่ทำให้ failover เป็นไปได้ - **Disk Group** คือหน่วยของการ "ถือครอง" · **import ได้ทีละเครื่องเท่านั้น** การย้ายงานคือการ deport ที่เครื่องหนึ่งแล้ว import ที่อีกเครื่อง - **เวอร์ชันของ disk group** เป็นตัวกำหนดว่า InfoScale รุ่นไหนอ่านได้ | InfoScale | DG version ตั้งต้น | |---|---| | 7.4.1 | 280 | | 7.4.2 | 290 | | 8.0 | 310 | | **8.0.2** | **320** | **กฎเหล็กเรื่องเวอร์ชัน disk group** > รุ่นใหม่ **อ่านของเก่าได้** เสมอ แต่ `vxdg upgrade` เป็น **ทางเดียว ย้อนกลับไม่ได้** ดังนั้นตอนยกระดับ InfoScale ถ้าไม่สั่ง `vxdg upgrade` เวอร์ชันของ disk group จะคงเดิม และ **เครื่องที่ยังเป็นรุ่นเก่ายังรับดิสก์กลับได้** นี่คือทางถอยที่ต้องรักษาไว้ตลอดการอัพเกรด --- ## 6. VCS — ชั้นตัดสินใจ องค์ประกอบ | ส่วน | หน้าที่ | |---|---| | `had` | High Availability Daemon — สมองของ cluster ตัดสินใจทุกอย่าง | | `hashadow` | เฝ้า `had` ถ้าตายให้ปลุกขึ้นมาใหม่ | | **agent** | โปรแกรมหนึ่งตัวต่อ resource หนึ่งชนิด เป็นมือเป็นเท้าให้ `had` | | `main.cf` | ไฟล์ config ที่เป็นสำเนาเหมือนกันทุก node | **agent ทำงานแค่ 4 อย่าง** และทุก resource type ต้องทำได้ครบ ```mermaid flowchart LR AG["Agent"] --> ON["online
สั่งให้ทำงาน"] AG --> OFF["offline
สั่งให้หยุด"] AG --> MON["monitor
ยังดีอยู่ไหม"] AG --> CLN["clean
เก็บกวาดเมื่อพัง"] ``` agent ที่พบบนเครื่องจริง — `DiskGroupAgent` `VolumeAgent` `MountAgent` `IPAgent` `NICAgent` ตรงกับ resource 5 ตัวใน `main.cf` พอดี **แต่ละตัวรันอยู่บนเครื่องของตัวเอง ไม่ได้รายงานไปไหน** --- ## 7. Service Group และผังการพึ่งพา **Service Group** คือกลุ่มของ resource ที่ต้องอยู่ด้วยกันเสมอ ย้ายก็ย้ายทั้งกลุ่ม ไม่มีการย้ายทีละชิ้น ผังจาก `main.cf` ของจริง ```mermaid flowchart TB MNT["Mount
/MZAPP_MNT"] --> VOL["Volume
DATA_VOL"] MNT --> VIP["IP
172.29.202.214"] VOL --> DG["DiskGroup
DATA_DG"] VIP --> NIC["NIC
ens33"] ``` อ่านว่า **ลูกศรชี้ไปหาสิ่งที่ต้องพร้อมก่อน** — `Mount` ต้องรอทั้ง `Volume` และ `IP` · `Volume` ต้องรอ `DiskGroup` · `IP` ต้องรอ `NIC` ดังนั้น - **ตอนเปิด** ไล่จากล่างขึ้นบน: NIC → DiskGroup → IP กับ Volume → Mount - **ตอนปิด** ไล่จากบนลงล่าง: Mount → IP กับ Volume → DiskGroup → NIC --- ## 8. ลำดับการย้ายงาน — failover ทีละขั้น ```mermaid sequenceDiagram autonumber participant OP as ผู้ดูแล participant N1 as NODE1 had participant N2 as NODE2 had participant D as Shared Disk OP->>N1: hagrp -switch GROUP -to NODE2 Note over N1: เริ่มปิดจากบนลงล่าง N1->>N1: MountAgent offline — umount /MZAPP_MNT N1->>N1: IPAgent offline — ถอด VIP N1->>N1: VolumeAgent offline — หยุด DATA_VOL N1->>D: deport DATA_DG D-->>N1: ปล่อยการครอบครองแล้ว N1->>N2: แจ้งผ่าน GAB ว่าปล่อยครบแล้ว Note over N2: เริ่มเปิดจากล่างขึ้นบน N2->>D: import DATA_DG D-->>N2: ได้สิทธิ์ครอบครอง N2->>N2: VolumeAgent online — start DATA_VOL N2->>N2: IPAgent online — ผูก VIP ที่ ens33 N2->>N2: MountAgent online — mount /MZAPP_MNT N2-->>OP: Group is ONLINE on NODE2 ``` **ช่องว่างที่หลายคนตกหลุม** — ลำดับนี้จบแค่ "ดิสก์พร้อมและ IP พร้อม" **ถ้าแอปพลิเคชันไม่ได้ถูกใส่เป็น resource ใน `main.cf` จะไม่มีใครสั่งเปิดแอปให้** ต้องมีสคริปต์ภายนอกมาทำส่วนนั้นเอง --- ## 9. เมื่อไหร่ที่มันย้ายเอง และเมื่อไหร่ที่ไม่ย้าย ```mermaid flowchart TB EV["เกิดเหตุ"] --> Q1{"ทั้ง node หายไปจาก cluster
GAB membership ลดลง"} Q1 -->|ใช่| FO["VCS ยกงานไปอีก node ให้เอง"] Q1 -->|ไม่| Q2{"resource ตัวใดตัวหนึ่ง fault"} Q2 -->|ไม่| OK["ไม่มีอะไรเกิดขึ้น"] Q2 -->|ใช่| Q3{"resource ตัวนั้นตั้ง Critical = 1 ไหม"} Q3 -->|"Critical = 1"| FO Q3 -->|"Critical = 0"| NOFO["ขึ้น FAULTED เฉย ๆ
ไม่ย้ายให้ ต้องสั่งเอง"] ``` **จุดที่ต้องตรวจเสมอหลังติดตั้งใหม่** — ผู้ติดตั้งมักตั้ง `Critical = 0` ไว้ทุก resource ระหว่างทดสอบแล้วลืมเปลี่ยนกลับ ผลคือ cluster ดูเหมือนพร้อมแต่จริง ๆ ไม่ย้ายให้เมื่อ resource พัง · ตรวจด้วย `hares -display -attribute Critical` --- ## 10. Split-brain กับ I/O fencing — เรื่องที่สำคัญที่สุด **ปัญหา** ถ้าสาย heartbeat ขาดหมดแต่ทั้งสองเครื่องยังมีชีวิต ต่างฝ่ายต่างคิดว่าอีกฝ่ายตาย แล้วต่างก็ import disk group → **เขียนทับกันทันที ข้อมูลพังถาวร** ```mermaid flowchart TB SP["สาย heartbeat ขาดทั้งหมด"] --> Q{"เปิด I/O fencing ไว้ไหม"} Q -->|"เปิด"| F1["แย่งกันจอง coordination point"] F1 --> F2["ฝ่ายที่ชนะ อยู่ต่อและถือดิสก์"] F1 --> F3["ฝ่ายที่แพ้ panic ตัวเองทิ้งทันที"] F2 --> SAFE["ข้อมูลปลอดภัย"] F3 --> SAFE Q -->|"ไม่เปิด"| N1["ทั้งสองเครื่องคิดว่าตัวเองควรถือ"] N1 --> N2["ถ้ามีใคร import ซ้อน"] N2 --> BAD["ข้อมูลเสียหายทันที
ไม่มีอะไรมาขวาง"] ``` **coordination point มี 2 แบบ** | แบบ | กลไก | |---|---| | **Disk-based** | ใช้ดิสก์พิเศษ 3 ก้อน จองด้วย SCSI-3 Persistent Reservation | | **Server-based** | ใช้ **CP Server** เป็นคนกลางตัดสิน | **ตรวจว่าเปิดอยู่ไหม** — ดู GAB port `b` และไฟล์ `/etc/vxfenmode` · ถ้าไม่มีทั้งสองอย่าง = ไม่ได้เปิด > **เมื่อไม่มี fencing ความปลอดภัยทั้งหมดไปตกอยู่ที่วินัยของคน** ก่อน import ที่เครื่องใด **ต้องยืนยันด้วยตาว่าอีกเครื่อง deport แล้วจริง** ไม่ใช่เชื่อว่าคำสั่งก่อนหน้าสำเร็จ --- ## 11. การอัพเกรดและกับดักที่เจอจริง ### 11.1 ลำดับที่ปลอดภัย ```mermaid flowchart TB S1["1. ย้ายงานออกจากเครื่องที่จะทำ
ให้เป็น node ว่าง"] --> S2["2. หยุด VCS บน node นั้น"] S2 --> S3["3. อัพ package ของ OS
*** ยังไม่ restart ***"] S3 --> S4["4. ยกระดับ InfoScale
*** ห้าม vxdg upgrade ***"] S4 --> S5["5. restart ครั้งเดียว
ใช้ shutdown -r now"] S5 --> S6["6. ตรวจว่า module โหลดครบ"] S6 --> S7["7. ให้ node กลับเข้า cluster"] S7 --> S8["8. ย้ายงานมาทดสอบ แล้วทำ node ถัดไป"] ``` **เหตุผลที่ขั้น 3 ห้าม restart** — ถ้า restart ตรงนั้น เครื่องจะบูตขึ้น kernel ใหม่ขณะที่ InfoScale ยังเป็นรุ่นเก่าที่ไม่มี module ของ kernel นั้น → `vxio` `llt` `gab` ไม่ขึ้น → cluster พัง · การอัพทั้งสองอย่างให้จบก่อนแล้ว restart ครั้งเดียว ทำให้ไม่มีวินาทีไหนที่ kernel กับ InfoScale ไม่เข้าคู่กัน **เหตุผลที่ต้องใช้ `shutdown -r now`** — คำสั่ง `reboot` ข้ามสคริปต์ตอนปิดเครื่อง ทำให้ cluster ไม่ได้ลาออกจากกลุ่มอย่างถูกต้อง ### 11.2 กับดักที่เจอจริง | กับดัก | อาการ | ทางแก้ | |---|---|---| | **module ผูกกับ kernel** | บูตแล้ว `vxio` ไม่โหลด `vxdctl mode: not-running` | บูต kernel เดิมจาก GRUB แล้วยกระดับ InfoScale ให้เสร็จก่อน | | **ติดตั้งแล้วไม่เคย reboot** | บูตครั้งแรกจริงแล้ว VxVM ไม่ขึ้นเอง `vxvm-boot.service` เป็น disabled | ต้องตรวจการ enable ตอนบูตก่อนนับว่าติดตั้งเสร็จ | | **`vxdg upgrade` หลุดมือ** | เครื่องรุ่นเก่า import ดิสก์กลับไม่ได้อีกเลย | ป้องกันอย่างเดียว ย้อนไม่ได้ | | **EDR ที่ดักไฟล์ด้วย fanotify** | ทั้งเครื่องแข็งกลางการอัพ สร้าง session ใหม่ไม่ได้ ทั้ง ssh และ console แต่ ping ยังตอบ | ทำ exclusion หรือปิด on-access scan ชั่วคราว และหยุด agent ไม่ให้ policy เขียนกลับ | | **probe port 22 ถี่ ๆ ตอนเครื่องแข็ง** | sshd คิวเต็ม ตอบ `Exceeded MaxStartups` ปฏิเสธทุกคน เข้าใจผิดว่า sshd ตาย | ดูสถานะผ่าน `gabconfig -a` และ `hasys -display` จาก node อีกตัวแทน | --- ## 12. วิธีอ่านสถานะเครื่องโดยไม่ต้องล็อกอินเข้าเครื่องนั้น เทคนิคที่มีประโยชน์มากตอนเครื่องมีปัญหา — **ถาม node อีกตัวแทน** ```mermaid sequenceDiagram participant ME as เครื่องเรา participant N1 as NODE1 ที่ยังปกติ participant N2 as NODE2 ที่เข้าไม่ได้ ME->>N1: ssh เข้าได้ตามปกติ N1->>N2: GAB heartbeat N2-->>N1: ยังตอบอยู่ ME->>N1: gabconfig -a N1-->>ME: membership 01 = NODE2 ยังมีชีวิต ME->>N1: hasys -display NODE2 N1-->>ME: SysState · CPU · Memory ของ NODE2 ``` ถ้า **GAB port h ยังมี membership ครบ** แปลว่า daemon `had` ซึ่งเป็น process ใน userspace ของเครื่องนั้น **ยังทำงานและตอบสนองอยู่** เป็นหลักฐานว่าเครื่องไม่ได้ตาย แค่บางบริการมีปัญหา --- ## 13. ค่าจริงจาก cluster ที่ใช้อ้างอิงในเอกสารนี้ | รายการ | ค่า | |---|---| | cluster | 2 node · peer-to-peer · ไม่มีเซิร์ฟเวอร์กลาง | | InfoScale | 8.0.2 · 28 package ต่อเครื่อง | | GAB port | `a` และ `h` เท่านั้น → **ไม่ได้เปิด I/O fencing** | | LLT | `ens36` และ `ens37` เป็นเส้นหลัก · `ens33` เป็นเส้นสำรอง | | disk group | `DATA_DG` · **version 320** · ดิสก์เป็น `cdsdisk` บน LUN จาก 3PAR 50 GB | | volume | `DATA_VOL` | | filesystem | VxFS · mount ที่ `/MZAPP_MNT` ด้วย option `mntlock=VCS` | | **`/etc/fstab`** | **ไม่มีบรรทัดของ mount นี้** — VCS เป็นเจ้าของ ห้ามใส่ | | VIP | `172.29.202.214` ผูกกับ `ens33` ของเครื่องที่ถือ group อยู่ | | resource | DiskGroup · Volume · Mount · IP · NIC รวม 5 ตัว | | `Critical` | ตั้งเป็น `0` ทุกตัว → **ไม่ย้ายเองเมื่อ resource fault** | | VIOM | ไม่ได้ลงทะเบียน — ไม่มี management server | --- ## 14. คำสั่งที่ใช้บ่อย ```bash # ----- อ่านอย่างเดียว ปลอดภัย ----- hastatus -sum # สถานะ node และ service group hasys -state # สถานะของทุก node hasys -display # รายละเอียดของ node หนึ่ง รวม CPU และ memory gabconfig -a # GAB port และสมาชิก — ดู port b เพื่อเช็ค fencing lltstat -nvv # สถานะของแต่ละเส้น heartbeat vxdctl mode # vxconfigd ทำงานไหม vxdg list # disk group ที่ import อยู่ vxdg list | grep version # *** เวอร์ชันของ disk group *** vxdisk -o alldgs list # ดิสก์ทั้งหมด วงเล็บ = import อยู่ที่เครื่องอื่น vxprint -g -ht # ผังของ disk group lsmod | grep -E 'vxio|vxdmp|vxfs|veki|gab|llt|amf' hares -display -attribute Critical cat /etc/VRTSvcs/conf/config/main.cf # ----- เปลี่ยนสถานะ ต้องรู้ว่าทำอะไรอยู่ ----- hagrp -switch -to # ย้ายงานไปอีกเครื่อง hagrp -offline -sys # นำงานลง hagrp -online -sys # นำงานขึ้น hastop -local # หยุด VCS เฉพาะเครื่องนี้ hastart # เริ่ม VCS # ----- ห้ามใช้ถ้าไม่ได้ตั้งใจจริง ๆ ----- # vxdg upgrade <-- ทางเดียว ย้อนกลับไม่ได้ ปิดทางถอยถาวร ``` --- ## 15. สรุปสิ่งที่ควรจำ 1. **ไม่มีเซิร์ฟเวอร์กลาง** ทุก node เท่าเทียมกัน ลงของเหมือนกัน config เหมือนกัน 2. **agent อยู่บนเครื่องเดียวกับ resource** ไม่ได้รายงานไปที่ไหน 3. **disk group import ได้ทีละเครื่อง** และนั่นคือทั้งหมดของการ failover 4. **ไม่มี fencing = ไม่มีอะไรกันข้อมูลพัง** นอกจากวินัยของขั้นตอน 5. **module ผูกกับ kernel** อัพ OS กับ InfoScale ต้องเข้าคู่กันเสมอ อย่าให้มีช่วงที่ไม่เข้าคู่ 6. **`vxdg upgrade` ย้อนไม่ได้** เก็บเวอร์ชันเดิมไว้คือเก็บทางถอยไว้ 7. **VCS จบหน้าที่ตรงที่ดิสก์และ IP พร้อม** แอปพลิเคชันเป็นคนละเรื่อง ต้องจัดการเอง

SECURE_ACCESS

DOWNLOAD_LOCKED

Veritas InfoScale ทำงานอย่างไร ฉบับเข้าใจกลไก

CONFIRM_DELETE