By Arnon Puitrakul - 09 ธันวาคม 2022
หลังจากเอา Synology NAS มาใช้งานอะไรสารพัดมาก ๆ จนล่าสุดเราเอามาทำ Video On Demand Server สำหรับ Online Course ที่กำลังจะเปิด แต่พอเราใช้งานพวก Multipart Upload มันจะมีจังหวะที่มันช้ามาก ๆ เพราะ SSD ที่เราใช้ เราไม่ได้เผื่อเรื่องพวกนี้มาด้วย ทำให้มันมี IOPS ไม่พอที่จะทำงานกับไฟล์เยอะ ๆ ใหญ่ ๆ ได้อย่างรวดเร็ว เลยทำให้เราจะต้องมา Upgrade SSD ในวันนี้กัน
หลาย ๆ คนอาจจะสงสัยว่า เห้ย ลูกเก่า เราก็เป็น NVMe อยู่แล้วนิ ทำไมเราถึงบอกว่ามันช้า ุถ้าเราเอามาใช้งานทั่ว ๆ ไป อย่างใน Synology ให้เราเอามาทำเป็น Cache มันก็เร็วมากพอแล้วแหละ เพราะ SSD อย่าง Intel 660p และ WD Blue SN550 ก็ทำความเร็วได้มากพอสมควรแล้ว แต่ปัญหาจริง ๆ มันไม่ได้อยู่ที่ความเร็วในการอ่านเขียนแบบตามลำดับ Sequential Read/Write แต่ปัญหาที่เราเจอเป็นเรื่องของ Random Read/Write มากกว่า ทำให้เราพิจารณาในการเปลี่ยน SSD รอบนี้
สำหรับอีกเรื่องที่เราค่อนข้างเป็นห่วงคือ การตั้งค่า SSD ทั้งสองลูกของเรา ใช้งานแบบ RAID0 เพื่อให้เราได้พื้นที่ และ ประสิทธิภาพสูงที่สุด แต่อย่างที่เราเล่าไปในบทความด้านบนว่า SSD ทั้ง 2 ลูกของเรามาจากคนละยี่ห้อ และ คนละ Spec กันเลย ทำให้เวลาเราอ่านเขียนหนักจริง ๆ เราเข้าไปดูที่ Disk Activity ตัวของ Intel 660p มันจะโดน Utilisation ไป 100% ในขณะที่ WD SN550 มันวิ่งอยู่แค่ 30-40% เท่านั้นเอง เราเลยเดาว่าปัญหาน่าจะเกิดจากความต่างของสเปกที่มันมากเกินไปหน่อย กับ SSD ของ Intel อันนั้นมันก็เก่าแล้วด้วยแหละมั้ง
สำหรับการย้าย ด้วยความที่ Disk Array อันที่เราจะเปลี่ยนมันเป็น RAID0 ทำให้เราจะต้องย้ายข้อมูลออกไปไว้ใน HDD ทั้งหมดก่อน เพื่อเป็นการสำรองข้อมูลไว้ เพราะใน RAID0 ถ้า Disk สักลูกหาย ก็เท่ากับ เราสูญข้อมูลทั้งหมดไปเลยนะ
ทำให้เราจะต้องเข้าไปดูว่า ใน SSD Array ของเรามันมีข้อมูลอะไรบ้าง ซึ่งหลัก ๆ ก็จะเป็นพวก VM, Docker App Data และ Package ต่าง ๆ ที่เราติดตั้งจาก Package Manager เราก็น่าจะต้องย้ายทั้งหมดนั่นลงไปใน HDD ก่อนแล้วละ โดยเพื่อให้ทุกอย่างมันราบลื่น เราเลยทำแผนมาทั้งหมดว่า เราจะต้องย้ายอะไรก่อนหลัง
โดยพวก Service ทั้งหลายที่เราใช้งานเยอะ ๆ อย่างพวก Home Assistant, Ghost และ Web Gateway ทั้งหลาย เราทำงานอยู่บน Docker ซะส่วนใหญ่ ทำให้เราจะเลือกทำพวกนี้หลักสุดเลย ทำให้เราเลยเรียงเป็น VM, Package, Docker และ App Data ของ Docker แบบนี้ละกัน
สำหรับการจัดการ VM เองเป็นเรื่องง่ายมาก ๆ เพราะใน Synology VM Manager (VMM) เขามี Tool ให้เราสามารถ Migrate ข้าม Volume กันได้ ทำให้ในขั้นตอนแรก เราจะต้องเข้าไปสร้าง Volume ที่อยู่บน HDD ของเราก่อน
จากนั้นเราสามารถปิดเครื่อง VM แล้วสั่ง Migrate ข้าม Volume ไปไว้ที่ HDD ได้ตรง ๆ เลย ซึ่งก็จะใช้เวลาสักนิดนึง เพราะ Disk Image มันมีขนาดค่อนข้างใหญ่มาก ๆ ระดับ VM ละ 90 GB หรือมากกว่าเลย เท่านี้ก็เสร็จเรียบร้อยแล้ว
อันนี้จะเอาให้ง่าย มันก็ได้นะ คือ เราทำการ Uninstall Package ผ่าน Package Manager แล้วเราทำการติดตั้งใหม่ลงไปใน Volume ที่เป็น HDD ได้เลย แต่ถ้าเราทำแบบนั้นเรากลัวเรื่องข้อมูลที่เราเก็บอยู่บนนั้นว่าถ้าเรากดลบแล้ว ลงใหม่พวกข้อมูลมันหายไปเลย มันจะฮ่าไม่ออกน่ะสิ
เราเลยไปนั่งหาว่า เราจะทำอย่างไรได้บ้าง เพื่อไม่ให้เราต้องมานั่งลบแล้วลงใหม่ เสี่ยงกับข้อมูลหาย เราเลยไปเจอวิธีในบทความหนึ่งมา ตอนแรกอ่านก็ไม่ได้คิดอะไร จนกระทั่ง.... เห็นว่า มันเป็นการย้ายแบบมือเลยนิหว่า
แบบมือจริง ๆ เพราะเราจะต้อง SSH เข้าไป อันนี้เราจะไม่แนะนำให้กับคนที่ไม่เคยใช้พวก Linux มาก่อนเลยนะ วิธีการที่เขาใช้คือ ใน Folder volume ที่เป็น SSD ของเรา มันจะมี Folder ชื่อว่า @appstore มันจะเก็บพวก Package ที่เราติดตั้งผ่าน Package Manager อยู่ เขาเลยเขียนมาให้เราสั่งย้ายมันไปที่ @appstore Folder ที่อยู่บน volume ที่เป็น HDD จากนั้น ในตัวของ Synology เองเพื่อให้มันจัดการได้ง่าย มันทำการสร้าง Symlink ขึ้นมาอยู่ใน Path ที่นึง เมื่อเราย้ายไปไว้ Volume ใหม่แล้ว ทำให้เราจะต้องไปลบ Symlink เก่า แล้วทำการสร้าง Symlink ใหม่ด้วยมือเรา ทำให้เราต้องใช้คำสั่งเยอะมาก ๆ เพราะมีหลาย Package อยู่ในนั้น
ซึ่งในระหว่างที่เราย้ายในหน้า Package Manager ก็คือเละเทะเลยจ้าาา เพราะเราลืม Stop Service ก่อน แตกรัว ๆ เลย พอเราย้ายแล้วทำ Symlink ใหม่มันก็หาย ใช้งานได้ปกติ เลยทำให้เราไม่ได้เป็นห่วงอะไรเท่าไหร่
อย่างที่เราบอกว่า ส่วนสำคัญจริง ๆ ของเครื่องเราอยู่ที่ Docker เป็นหลักเลย ทำให้เวลาเราจะทำอะไรกับตรงนี้ เราจะระวังเป็นอย่างมาก และ Docker เอง ก็เป็น Package หนึ่งที่เราติดตั้งจาก Package Manager ด้วย ทำให้เราก็ใช้วิธีการย้ายแบบที่เราเล่าไปในหัวข้อก่อนหน้านั้นแหละ ซึ่งมันก็ดูเหมือนจะใช้งานได้ปกติดีแล้ว
จนเราก็ซนนะ เราเห็นอีก Folder นึงชื่อว่า @appdata เราเดาว่า มันน่าจะเก็บพวก Data ของ Application นี่แหละ เลยเข้าไปดูแล้วเจอกับพวกข้อมูลทั้งหลาย อย่างของ Docker เองมันเป็น YAML หรือ JSON ไว้ระบุพวก Container Definition นั่นแหละ เราเลยเข้าใจว่า ถ้าเราเอา SSD ออก Volume นี้มันก็จะต้องหายไปแล้วสิ เราเลยสาระแน ย้ายไปไว้ใน @appdata ของ Volume ที่เป็น HDD สุดท้าย Docker รันไม่ขึ้น ใน Package Manager บอกให้กด Repair พอมันเสร็จ มันก็ใช้งานได้ไม่มีปัญหาอะไร
สำหรับข้อมูลที่อยู่ใน Container ในหลาย ๆ Container ที่สำคัญ เราจะมีการ Mount Folder ออกมาไว้ เผื่อเวลาเรา Update หรือเกิดเหตุไม่คาดคิดนี่แหละ ดังนั้นข้อมูลพวกนี้สำคัญมาก ๆ ต้องรักษาไว้ยิ่งชีพเลย และตอนนี้มันอยู่ใน Volume ของ SSD ทำให้ก่อนที่เราจะย้าย เราก็จะรัน Backup Routine ใน Hyperbackup ให้มันจัดการให้เราก่อน
เนื่องจากเราทำออกมาเป็น Shared Folder ทำให้เราสามารถเข้าไปที่ Control Panel > Shared Folder แล้วเลือก Volume ของ Docker Share Folder ไปอยู่ใน Volume ที่เป็น HDD ก็จะใช้เวลาสักแปบในการย้าย เสร็จก็จบแล้วเรียบร้อย
แต่ ๆๆๆ หลังจากย้ายเสร็จ เราก็เจอปัญหาว่า Container แตกหมดเลย เพราะมันมีการ Mount Volume เอาไว้ พอเราย้ายในความเป็นจริง มันมีการย้าย Path เลย จากเดิมเป็น /volume3/docker มันจะกลายเป็น /volume1/docker พวกนี้เราก็แก้ไม่ยาก เราก็แค่เข้าไปทยอยแก้พวก Mount Path ของแต่ละ Container ก็เรียบร้อยแล้ว
หลังจากที่เรามั่นใจแล้วว่าข้อมูลทั้งหมดถูกสำรอง หรือย้ายไปไว้ใน HDD ทั้งหมดแล้ว เราก็ปิดเครื่องเลย
อย่างที่เราเล่าไว้ในบทความ Upgrade DS1621+ ตัว SSD เป็นอะไรที่ใส่ง่ายมาก ๆ แบบไม่ต้องใช้เครื่องมืออะไรเลย แค่เราดึง HDD ออกมาสัก 2-3 ลูกตัว เพื่อให้มีพื้นที่มากพอที่เราจะถอด และ ใส่ SSD ได้ง่าย ๆ ดูจากในรูปคือ สภาพที่เราใช้งานมา 1 ปี แบบ พอดีเป๊ะ ๆ เลย ฝุ่นเยอะมาก ๆ อยู่นะ SSD ลูกด้านหน้าคือ ฝุ่นแบบเกาะเยอะอยู่
ถ้าเราดูกันใกล้ ๆ เราจะเห็นว่า ฝุ่นส่วนใหญ่มันจะเป็นพวกฝุ่นละเอียด ๆ ซะเยอะนะ ไม่ค่อยเจอแบบเป็นก้อน ๆ อะไรเท่าไหร่ แปลว่าห้องที่เราใช้เก็บก็ถือว่า พอใช้ได้เลยละกัน ส่วนนึงเป็นเพราะเราไม่ค่อยได้เปิดใช้งานอะไรเท่าไหร่เลยทำให้มันก็อยู่ในห้องที่ฟอกอากาศตลอดเวลา
ซึ่ง SSD ที่เรา Upgrade เข้าไปใหม่จะเป็น WD SN750 ซึ่งเป็นตัวแรงเลยก็ว่าได้ ถ้าเราเทียบสเปกกับตัวเก่าอย่าง SN550 แล้ว สิ่งที่เราต้องการมาก ๆ อย่าง Random Read/Write ของเดิม มันอยู่ที่ 300k และ 240k ตามลำดับ แต่ตัวใหม่ SN750 นั่นกดไป 420k และ 380k ตามลำดับเลย แค่ Random Write ที่น่าจะช้าสุดแล้วก็ยังเร็วกว่า Random Read ของตัวเดิมเลย น่าจะเร็วกว่าเยอะมาก ๆ
จากนั้นเราก็ทำการติดตั้ง SSD ลูกใหม่เข้าไปเป็นอย่างที่เห็นในรูปเลย เป็นรุ่นเดียวกันแล้วน่าจะตัดปัญหาที่เราเจอมานะ หวังว่า......
เมื่อติดตั้ง SSD เสร็จ เราก็ทำการติดตั้ง HDD กลับเข้าไปเหมือนเดิม เราไม่รู้ว่า ถ้าเราใส่สลับลูกกันมันจะเป็นอะไรมั้ย ดังนั้น เพื่อความปลอดภัย เวลาเราถอดออกมา เราเลยเรียงให้เป็นลำดับชัด ๆ เลย เวลาใส่ เราจะได้มั่นใจว่า เราใส่ในลำดับเดิม จะได้เลี่ยงปัญหาที่อาจจะเกิดขึ้นได้
ถึง The Moment of Truth กันแล้ว คือการเปิดเครื่อง ซึ่งก็ดูจะไม่มีอะไร จนกระทั่งเมื่อเราเปิดเครื่องไปมันก็มีไฟ Alert ขึ้นมา พร้อมกับเสียง Beep เป็นจังหวะเรื่อย ๆ เลย
จนเปิดเครื่องแล้วเราเข้า DSM ได้ มันก็บอกเลยว่า Volume ตัว Disk มันหายไป อะก็เข้าใจได้ ปกติแหละ ก็เราเป็นคนนึงมันออกเองนิน่าว่าไม่ได้ปะ
เนื่องจากเราไม่สามารถ Recover Volume ได้อยู่แล้ว เพราะ Disk หายไป 100% เลย วิธีเดียวที่ทำได้คือ เราก็ลบ Volume และ Storage Pool ของ SSD เก่าออกไป แล้วทำการสร้างใหม่ ตอนลบอะไม่ยากเท่าไหร่ แต่ตอนสร้างอะสิ
เพราะในความเป็นจริง DSM ไม่ยังไม่อนุญาติให้เราเอา SSD มาสร้างเป็น Storage Pool ได้ ให้เอามาทำเป็น Cache Tier อย่างเดียวเลย ทำให้เราจะต้องใช้ท่ายากนิดหน่อยในการสร้าง พวก DSM จริง ๆ พื้นฐานมันก็มาจาก Linux นี่แหละ ถ้าเรา SSH เข้าไปได้ เราก็สามารถสร้าง Storage Pool และ Volume ขึ้นมาได้ ใช้เวลาไม่นานเลย เราก็สามารถสร้าง Storage Pool ที่เป็น RAID0 ขึ้นมา อันนี้บอกเลยว่า แรงส์ แน่นอน SSD รุ่นเดียวกัน ขนาดเดียวกัน และ ที่ใส่ไปรุ่นใหญ่ด้วย
ถึงอีกจังหวะที่สนุกแล้วนั่นคือ การ Restore ข้อมูลทั้งหมดลงมา เราก็จะเล่าทำสวนทางกับตอนที่เรา Backup เลย เริ่มจากการย้ายพวก Appdata ของ Docker กลับไปไว้บน SSD ก็ทำเหมือนกันกับตอนที่เราเอาไปยัดใส่ HDD เลย แค่กลับกันเอาไปใส่ใน SSD ก็จบแล้ว
ทุกอย่างเลย เราก็แค่ทำกลับด้านไปก็เท่านั้นก็ถือว่าจบเลย แต่สิ่งนึงที่เราไม่ย้ายกลับไปแล้วคือพวก Package ที่ติดตั้งบน Package Manager เพราะส่วนใหญ่ที่เราใช้งานมันไม่ได้ต้องการพวก IOPS หรือ Sequential Read/Write เยอะมากจน HDD มันรับไม่ไหวแน่นอนเราเลยเอาไว้งั้นดีกว่า ย้ายก็เหนื่อยยากด้วย
แต่ ๆๆๆๆ ความชิบหายก็เกิด เพราะ Docker มัน Start ไม่ขึ้น ชิบหาย !!!!! ใน Package Manager มันให้เรากด Repair อย่างเดียว แล้วกดไปมันก็ Start ไม่ได้ ไม่รู้จะทำอย่างไร เราก็เลยกลั้นใจ ลบ Docker Package ออกแล้วติดตั้งใหม่ ก็รันได้ปกติ
แต่อีกแล้ว แต่ ๆๆๆๆๆๆ พวก Container เราหายหมดเลย ชิบหายยยยย แต่ความโชคดีคือ พวก Appdata ที่สำคัญมันยังอยู่ครบแหละ ความยากคือ เราจะต้องมานั่งไล่สร้าง Container ใหม่หมดเลย ถือว่าเหนื่อยอยู่เหมือนกัน เพราะเราจะต้องไปนั่งหาว่า Service ต่าง ๆ เราเอาไว้ Port ไหนอะไรยังไงบ้าง ซึ่งก็โชคดีที่ เรามี SWAG แล้วใน Nginx เราก็เขียนไว้หมดแล้ว เราเลยลอกตามนั้นได้เลย ชิว ๆ
เหตุการณ์ทั้งหมดนี้จบใน 6 ชั่วโมงด้วยกัน ตอนแรก เราก็กะอยู่แหละว่า ไม่น่าจะเกิน 2 ชั่วโมงหรอก แต่ไปติด เพราะ Docker Container ที่หายไปนี่แหละ แล้ว Service เราก็เยอะด้วย เลยทำให้ใช้เวลานานมาก ๆ ในการสร้างกลับมาใหม่ แต่ก็ถือว่าเป็นประสบการณ์ที่สนุกดี และ ถือว่า หาทำพอสมควร เขาให้ช่อง NVMe มาเพื่อทำ Cache อีนี่อยากเอามาทำ Storage Pool เฉย แล้วทำ RAID0 ด้วยนะ ไม่แนะนำให้เลียนแบบจริง ๆ หวังว่า ในอนาคต Synology จะเพิ่มตัวเลือกให้เราสามารถใช้งาน SSD ของเราเป็น Storage Pool แบบ Official ได้ โดยไม่ต้องไปแอบ SSH เข้าไปแล้ว งง ไปอีก เสี่ยงต่อการทำพังมาก ๆ
หลังจากเมื่อหลายอาทิตย์ก่อน Apple ออก Mac รัว ๆ ตั้งแต่ Mac Mini, iMac และ Macbook Pro ที่ใช้ M4 กันไปแล้ว มีหลายคนถามเราเข้ามาว่า เราควรจะเลือก M4 ตัวไหนดีถึงจะเหมาะกับเรา...
จากตอนก่อน เราเล่าเรื่องการ Host Website จากบ้านของเราอย่างปลอดภัยด้วย Cloudflare Tunnel ไปแล้ว แต่ Product ด้าน Zero-Trust ของนางยังไม่หมด วันนี้เราจะมาเล่าอีกหนึ่งขาที่จะช่วยปกป้อง Infrastructure และ Application ต่าง ๆ ของเราด้วย Cloudflare Access กัน...
ทุกคนเคยได้ยินคำว่า Mainframe Computer กันมั้ย เคยสงสัยกันมั้ยว่า มันต่างจากเครื่องคอมพิวเตอร์ที่เราใช้งานกันทั่ว ๆ ไปอย่างไรละ และ Mainframe ยังจำเป็นอยู่มั้ย มันได้ตายจากโลกนี้ไปหรือยัง วันนี้เรามาหาคำตอบไปด้วยกันเลย...
เคยมั้ยเวลา Deploy โปรแกรมสักตัว เราจะต้องมานั่ง Provision Infrastructure ไหนจะ VM และ Settings อื่น ๆ อีกมากมาย มันจะดีกว่ามั้ยถ้าเรามีเครื่องมือบางอย่างที่จะ Automate งานที่น่าเบื่อเหล่านี้ออกไป และลดความผิดพลาดที่อาจจะเกิดขึ้น วันนี้เราจะพาทุกคนมาทำความรู้จักกับ Infrastructure as Code กัน...