ในงาน 2016 USENIX conference on File and Storage Technologies (FAST 2016) ที่ผ่านมา Eric Brewer ผู้ดำรงตำแหน่ง VP Infrastructure แห่ง Google ได้ออกมากล่าวถึงความพยายามในการพัฒนา Disk แบบใหม่ที่ตอบโจทย์ของการสร้างบริการ Cloud-based Storage ภายใน Data Center ให้มากขึ้นกว่าเทคโนโลยีที่มีอยู่ในปัจจุบัน พร้อมระบุ Disk แบบ Nearline นั้นไม่เหมาะสมต่อระบบ Cloud อีกต่อไป
ตัวอย่างหนึ่งที่ทาง Google ได้หยิบยกขึ้นมาก็คือกรณีการใช้งานของ YouTube ที่ภายในเวลาเพียง 1 นาทีก็มีเหล่าผู้ใช้งานจากทั่วโลกทำการ Upload วิดีโอขึ้นมาเป็นความยาวรวมกันถึง 400 ชั่วโมงแล้ว ซึ่งถ้าหากเทียบง่ายๆ ว่าวิดีโอความยาว 1 ชั่วโมงนั้นใช้พื้นที่ 1GB ด้วยอัตราการเติบโตของข้อมูลระดับนี้แล้วก็แปลว่า YouTube จะต้องการ Storage เพิ่มเติมวันละ 1 Petabyte (1,000,000GB) เลยทีเดียว และปริมาณการอัพโหลดวิดีโอบน YouTube นี้ก็เติบโตมากถึง 10 เท่าในทุกๆ 5 ปี
แต่ถ้าหากมองย้อนกลับมาที่เทคโนโลยี Enterprise Hard Drive อย่างกลุ่มเทคโนโลยี Nearline นั้นก็ไม่ได้ถูกออกแบบมาเพื่อรองรับการเติบโตของปริมาณข้อมูลขนาดนี้ แต่กลับไปพัฒนาเพื่อตอบรับการใช้งานของ Server แบบเดิมๆ แทน ดังนั้น Google จึงเชื่อว่าเวลานี้คือเวลาที่เหมาะสมในการที่เหล่าผู้ผลิตและมหาวิทยาลัยต่างๆ จะร่วมมือกันเพื่อพัฒนาเทคโนโลยี Hard Drive แบบใหม่เพื่อตอบโจทย์ของ Data Center ขนาดใหญ่และแก้ปัญหาที่เคยมีใน Hard Drive แบบเก่าๆ ร่วมกัน
แนวคิดหลักที่ Google เสนอขึ้นมาก็คือการมอง Disk ภายใน Data Center ให้เป็นกลุ่ม (Collection) แต่แรก และ Optimize ที่ระดับนั้นไปเลยทีเดียว เพราะภายในการใช้งานระดับ Data Center ขนาดใหญ่นั้นก็แทบจะไม่มีการใช้งาน Disk เป็นลูกเดี่ยวๆ อยู่แล้ว และการออกแบบเทคโนโลยีใหม่นี้ก็มีเป้าหมาย 5 ประการดังนี้
- เพิ่ม IOPS ให้มากขึ้น
- เพิ่ม Capacity (GB) ให้มากขึ้น
- ลด Tail Latency ลง ให้ 99% ของการอ่านข้อมูลมี Latency ในขอบเขตที่ต้องการ
- มีความปลอดภัยมากขึ้น ทั้งในระดับของ Firmware และการเข้ารหัสข้อมูล
- ลดค่า Total Cost of Ownership (TCO) ลง
ทั้งนี้ Google ยังได้เสนอแนวทางการออกแบบ Hard Drive แบบใหม่นี้ด้วยกันคร่าวๆ 10 ข้อ ซึ่งทีมงาน TechTalkThai ขอสรุปมาคร่าวๆ ดังนี้
- ออกแบบ Form Factor ใหม่ให้ตอบโจทย์ด้าน TCO, IOPS และ Capacity เพิ่มขึ้น เพราะขนาดของ HDD ที่ใช้กันอยู่ในปัจจุบันนี้อ้างอิงมาจาก Floppy Disk และไม่ได้มีเหตุผลอื่นที่ดีพอเลย โดย Gogole เสนอให้เพิ่มความสูงให้ 3.5″ Disk อีก 1″ และเพิ่มความสูงให้ 2.5″ Disk อีก 15 มิลลิเมตรเพื่อให้เพิ่ม Platter เข้าไปได้อีก โดยออกแบบให้รองรับ Parallel Access เพื่อเพิ่ม IOPS, รวม Disk หลายลูกเข้ามาเป็นชุดเดียว และใช้ไฟ 12V DC ที่กำลังส่งสูงสุดเท่านั้น
- ย้าย Cache ออกจาก Disk แต่ละลูกมารวมกันไว้ตรงกลางและใช้ร่วมกัน ทำให้ขนาดของ Cache เพิ่มขึ้น และสามารถปรับแต่งพฤติกรรมต่างๆ ได้ตามต้องการ โดยอาจจะใช้ RAM ของ Server เป็น Cache แทนและเชื่อม Disk หลายๆ ลูกเข้ามาทีเดียวผ่าน PCI-E ก็ได้
- ปรับปรุงเทคโนโลยี SMR ให้ดีขึ้น โดยหนึ่งในทางเลือกที่น่าสนใจก็คือการทำ Hybrid Drive ระหว่าง SMR และ CMR เพื่อให้รองรับได้ทั้ง Hot Data และ Cold Data พร้อมๆ กัน รวมถึงการลดทรัพยากรที่ใช้ในการทำ Garbage Collection ให้น้อยลงด้วยการปรับปรุงให้ดีขึ้น
- มีระบบตรวจสอบพฤติกรรมการเข้าถึงข้อมูล เพื่อให้ผู้ดูแลระบบเข้าใจการทำงานในเชิงประสิทธิภาพมากขึ้น โดยสามารถตรวจสอบเวลาที่ใช้ในการทำ Seeking, เวลาที่ใช้ในการส่งข้อมูลสำหรับการ Read และเวลาที่ใช้ในการแก้ไข Error ที่เกิดขึ้น
- ปรับแต่งการทำ Read Retries ได้ตามต้องการ เพื่อให้ Server ที่ทำการอ่านข้อมูลต่างๆ ได้รับ Error ตอบกลับไปให้เร็วที่สุด และทำให้การตอบสนองของระบบโดยรวมเป็นไปได้ด้วยความเร็วสูงสุด
- ยอมรับ Error Rate ที่สูงขึ้นได้ แลกกับการเพิ่มความจุ และลด Tail Latency ลง เพราะในการใช้งาน Disk จำนวนมากๆ นั้น การเกิด Error บ้างก็ไม่ใช่ปัญหาแต่อย่างใด เพราะระบบก็ยังสามารถอ่านข้อมูลที่ถูกต้องจาก Disk อื่นๆ ได้อยู่ดี
- ปรับปรุง Background Task และเพิ่ม Background Management API เพื่อให้สามารถปรับแต่งและควบคุมพฤติกรรมของ Disk ให้เป็นไปในรูปแบบที่ต้องการได้เมื่อข้อมูลเกิดเสียหาย และเพิ่มกรณีการทำงานร่วมกันระหว่าง Disk หลายลูกเข้าไปด้วย
- เปลี่ยนความจุแบบตายตัว ให้กลายเป็นความจุแบบ Flexible แทน เพื่อให้ Disk ที่ถูกผลิตออกมาและมีปัญหาใน Platter สามารถถูกนำออกมาขายใหม่ด้วยความจุที่ลดลงได้ เป้นการประหยัดค่าใช้จ่ายลงทั้งสำหรับผู้ผลิตและผู้ซื้อ รวมถึงนำ Reserved Sector ให้เอาออกมาใช้ทำอย่างอื่นได้ และ Disk ควรจะทำงานต่อได้ด้วยความจุที่น้อยลงเมื่อ Drive Head เกิด Fail ขึ้นมา
- เพิ่ม Sector Size ให้กลายเป็น 64KiB หรือใหญ่กว่านั้น และให้ไปทำการตรวจสอบความผิดพลาดและซ่อมแซมกันด้วย Distributed File System เอง
- ปรับปรุง Queuing Management ให้ดีขึ้น เพื่อให้ตอบโจทย์ต่อ Latency ที่ต้องการ และ Throughput สำหรับผู้ใช้งานแต่ละคนได้ในระดับที่เหมาะสม โดยระบบ Disk Scheduler จะต้องถูกปรับปรุงให้ทำงานคล้ายกับ Real-time Operating System (RTOS) และรองรับการทำ Queuing ได้ดีขึ้น รวมถึงรองรับ API สำหรับควบคุมการปรับแต่งพฤติกรรมของ IO จาก Server โดยตรง
ใครที่สนใจ Whitepaper ฉบับเต็ม สามารถเข้าไปอ่านได้จากที่ https://research.google.com/pubs/pub44830.html ทันทีเลยครับ
ที่มา: http://googlecloudplatform.blogspot.com/2016/02/Google-seeks-new-disks-for-data-centers.html