แนวโน้ม I / O แบบสุ่มมีแนวโน้มที่แม่นยำสำหรับการวางแผนกำลังการผลิต

ที่ทำงานของฉันเรามีเซิร์ฟเวอร์ "เหล็กขนาดใหญ่" จำนวนมากซึ่งใช้สำหรับการโฮสต์เครื่องเสมือนจำนวนมากโดยใช้ Xen Hypervisor โดยทั่วไปแล้วจะได้รับการกำหนดค่าด้วย RAM 32GB กระบวนการแบบดูอัลคอร์ Quad และดิสก์ที่รวดเร็วด้วยความจุ I / O

เราอยู่ในช่วงเวลาที่การกำหนดค่าฮาร์ดแวร์ที่มีอยู่เริ่มยาวขึ้นเล็กน้อยและถึงเวลาที่ต้องออกไปข้างนอกและหาแหล่งใหม่ที่ใหญ่กว่าเร็วขึ้นและมีฮาร์ดแวร์ใหม่ที่ดีกว่า

ดังกล่าวข้างต้นชุดที่มีอยู่ได้รับการปรับใช้กับ RAM 32GB และที่ จำกัด จำนวนของ VMs ที่เราสามารถปรับใช้กับโฮสต์ได้อย่างมีประสิทธิภาพ

ในการตรวจสอบฮาร์ดแวร์ที่ใหม่กว่านั้นเห็นได้ชัดว่าคุณสามารถรับ RAM ได้มากขึ้นภายในเครื่องเดียวด้วย 64, 72 หรือแม้กระทั่ง 96GB ภายในแชสซีเดียว เห็นได้ชัดว่าสิ่งนี้จะช่วยให้เราได้รับเครื่องมากขึ้นไปยังโฮสต์ที่กำหนดซึ่งมักจะชนะ การวิเคราะห์เสร็จสมบูรณ์จนถึงขณะนี้ชี้ให้เห็นว่าปัจจัยการ จำกัด ในขณะนี้จะถูกย้ายไปยังระบบย่อยของดิสก์

ปัญหาอยู่ในขณะนี้พยายามทำความเข้าใจว่าเราอยู่ที่ไหน ... ด้วยเหตุที่การใช้งานเรารู้ว่าเราไม่ได้ จำกัด ในเรื่องแบนด์วิดธ์ของ I / O มากขึ้นจำนวนการสุ่มฉัน / การดำเนินการ O ซึ่งสามารถทำให้สำเร็จ .. เรารู้มาก่อนว่าเมื่อเราไปถึงจุดนี้แล้ว iowait กำลังจะขึ้นไปบนท้องฟ้าจรวดและประสิทธิภาพของเครื่องจักรทั้งหมดจะไปหาสุนัข

ตอนนี้เป็นคำถามที่ฉันถามใครจะรู้วิธีที่จะติดตาม / แสดงแนวโน้ม I / O ที่มีอยู่อย่างแม่นยำโดยเฉพาะเกี่ยวกับจำนวน I / O แบบสุ่มที่เสร็จสมบูรณ์หรือไม่

สิ่งที่ฉันกำลังพยายามจะใช้เป็นตัวชี้วัดคือ "การกำหนดค่านี้สามารถจัดการการร้องขอ I / O แบบสุ่มได้จำนวน X และตอนนี้เรา (โดยเฉลี่ย) กำลังทำ Y ops ด้วยยอด Z ops"

ขอบคุณล่วงหน้า!

sarทำงานที่นี่อย่างดี มันจะรวบรวมจำนวนการทำธุรกรรมเช่นเดียวกับภาคการอ่าน / เขียนต่อวินาทีซึ่งสามารถใช้ในการเล่นซ้ำปริมาณงาน IO ของคุณด้วยความแม่นยำที่ค่อนข้างดี (ในแง่ของอัตราส่วนการอ่าน / เขียนเช่นเดียวกับขนาดของธุรกรรมซึ่งเป็น การพิจารณาปัจจัยในการ "สุ่ม" IO ของคุณ) มันไม่สมบูรณ์แบบ แต่จากประสบการณ์ของฉันมันทำงานได้ดีพอที่จะทำการประมาณแบบที่คุณกำลังดูอยู่

ดังนั้นนี่เป็นปัญหาการรายงานการตรวจสอบและกำลังการผลิต หากคุณกำลังจะเริ่มต้นวัดสถิติที่มีแนวโน้มฉันจะไปทั่วกระดานเพื่อให้คุณสามารถเปรียบเทียบเชื่อมโยง ฯลฯ

ในแง่ของเครื่องมือคุณมี ganglia, zenoss, nagios และอื่น ๆ ในโลก opensource และผลิตภัณฑ์อื่น ๆ ของผู้จำหน่าย

คุณสามารถกำหนดค่าให้ติดตามวัดและจัดเก็บ KPI ที่คุณสนใจแล้วรายงานเป็นระยะ ๆ

ด้วยคำสั่งของคุณเกี่ยวกับการใช้ RAM มันจะมีเหตุผลที่จะรวมสถิติหน่วยความจำการใช้งานการสลับและ CPU ด้วยดังนั้นคุณสามารถเปรียบเทียบข้อมูลเหล่านั้นทั่วทั้งกระดานในช่วงเวลาเดียวกันและดูว่ามีข้อ จำกัด อื่น ๆ หรือไม่

เมื่อคุณรวบรวมข้อมูลคุณสามารถเก็บข้อมูลทั้งหมดไว้ในฐานข้อมูลขนาดใหญ่ที่ดีสำหรับการรายงานซึ่งอาจจะทำการหาข้อมูลในอดีตเช่น เก็บทุก ๆ 5 วินาทีเป็นเวลา 6 เดือนจากนั้นนาทีละ 5 จากนั้นต่อชั่วโมงตามที่คุณกลับไป สิ่งนั้นสามารถเขียนสคริปต์และเรียกใช้ผ่าน cron, autosys เป็นต้น

รายงานเหล่านั้นจะให้สิ่งที่ฝ่ายบริหารต้องการเช่น บางสิ่งที่มีกราฟสวย

และสำหรับการจัดการรายวันคุณสามารถดูข้อมูลแบบเรียลไทม์บนแผนภูมิ / ตัวเลขผ่านคอนโซลเพื่อดูว่าคุณมีประสิทธิภาพอย่างไรในช่วงเวลาใดก็ตาม

เราใช้collectlเนื่องจากเราสามารถดึงข้อมูลที่จำเป็นทั้งหมดไว้ในไฟล์เดียวและเล่นซ้ำสถิติที่ต้องการ สิ่งนี้จะช่วยให้คุณเห็นจำนวนของ IOPS ต่อช่วงเวลาการบันทึกสวิตช์บริบทสถิติหน่วยความจำ คุณสามารถแยกย่อยลงนี้ต่อดิสก์หรือดูระบบโดยรวม Collectl ยังรองรับความมันวาว

นี่เป็นเครื่องมือที่ยอดเยี่ยมในการรับภาพรวมของประสิทธิภาพของระบบทั้งหมด ขอให้โชคดีจากการสังเกตดิสก์ SATA โดยทั่วไปจะอยู่ระหว่าง 200-300 IOPS เมื่อเข้าถึงแบบสุ่ม

เราบันทึกและกราฟดิสก์ I / O ในลักษณะเดียวกับที่เราทำกับตัวชี้วัดอื่น ๆ ทั้งหมด:

• ข้อมูลถูกดึงจากโฮสต์โดยใช้ SNMP กล่อง NAS / SAN ของเราทำสิ่งนี้โดยกำเนิด เราใช้สุทธิ SNMPในทุกครอบครัวลินุกซ์ซึ่งให้ข้อมูลนี้จากUSB-DISKIO-MIB

• ข้อมูลจะถูกเก็บไว้ (ในรูปแบบ RRD) และกราฟใช้Cacti เท็มเพลต Disk IOบางตัวให้จำนวนและขนาดของธุรกรรมที่แสดงในรูปแบบปัจจุบันค่าเฉลี่ยและรูปแบบสูงสุดตามปกติ

ตัวชี้วัดเหล่านี้ไม่จำเป็นต้อง จำกัด เหมือนการใช้iostat/ dstat/ sarบนโฮสต์ แต่มันเป็นไฟและลืมซึ่งได้รับการติดตั้งโดยอัตโนมัติเมื่อเครื่องใหม่ได้รับมอบหมายเก็บไว้ที่ส่วนกลางและยังคงพร้อมใช้งานสำหรับการอ้างอิงในอนาคต

เราใช้ข้อมูลนี้เพื่อแจ้งเตือนเราเกี่ยวกับแนวโน้มที่ผิดปกติบนพื้นฐานการดำเนินงานและมองย้อนกลับไปทุกครั้งที่ดำเนินการวางแผนกำลังการผลิต

สิ่งที่ฉันกำลังพยายามรับเมตริกคือ "การกำหนดค่านี้สามารถจัดการคำขอสุ่ม I / O จำนวน X ได้สำเร็จ [.. ]"

มีปัญหาสองสามข้อในเรื่องนี้:

• มันค่อนข้างยากที่จะแยกและหาปริมาณ I / O สุ่มจาก I / O ตามลำดับ เนื่องจากความแตกต่างพื้นฐานระหว่างสองคือตำแหน่งทางกายภาพของบล็อกที่เก็บไว้ในแผ่นดิสก์ คุณสามารถคาดเดาการศึกษาจากขนาดของทรานแซคชันได้เนื่องจากทรานแซคชันขนาดเล็กจำนวนมากอาจเกี่ยวข้องกับไฟล์ขนาดเล็กที่มีจุดเกี่ยวกับดิสก์ แต่ไม่มีการรับประกัน มันอาจกำลังอ่านข้อมูลปริมาณเล็กน้อยตามลำดับจากไฟล์เดียวหรือบล็อกที่อยู่ติดกันบนดิสก์

• การบันทึกเมทริกจะให้ภาพที่ดีมากแก่คุณเกี่ยวกับข้อผูกพันของคุณในวันนี้ว่าพวกเขามีการเปลี่ยนแปลงอย่างไรเมื่อเวลาผ่านไปและพวกเขาจะเปลี่ยนแปลงอย่างไรในอนาคต สิ่งที่มันจะไม่บอกคุณคือเพดานคืออะไร อย่างน้อยไม่ก่อนที่มันจะสายเกินไป ในการพิจารณาสิ่งนี้คุณต้องทำคณิตศาสตร์ (จากสเป็คฮาร์ดแวร์ของคุณ) การเปรียบเทียบ (ฉันชอบbonnie++ตนเอง) และเป็นประโยชน์ที่จะมีความคิดด้านลอจิสติกส์ว่ามีการทำ / ใช้งาน domUs เหล่านั้นอย่างไร

ขึ้นอยู่กับแบ็กเอนด์หน่วยเก็บข้อมูลของคุณ (IBM SVC / DS8000) คุณอาจจะสามารถดึงสถิติที่เกี่ยวข้องกับการสุ่ม IOPS จากมันโดยตรง

สำหรับการดึงสถิติจากเซิร์ฟเวอร์คุณสามารถใช้NMON ฟรี (เหมือนอยู่ในเบียร์) เริ่มแรกพัฒนาโดย IBM สำหรับ AIX ยังทำงานบน Linux

หากผู้คนใช้ SAR ฉันอย่างน้อยก็หวังว่าคุณจะสุ่มตัวอย่างข้อมูลของคุณไม่กี่วินาที เมื่อฉันใช้ collectl ฉันสุ่มตัวอย่างหนึ่งครั้ง / วินาที เท่าที่วัดได้ว่าคุณทำได้ดีแค่ไหนในการสุ่ม I / O ให้ใช้เครื่องมือเช่น dt ของ Robin Miller และคุณสามารถสร้าง I / Os สุ่มจำนวนมากได้อย่างง่ายดายจากนั้นก็วัดด้วย collectl เพื่อดูว่าคุณมีเท่าไหร่ สามารถทำต่อวินาที โดยทั่วไปดิสก์ทั่วไปจะมีค่าสูงสุด 200-300 I / Os / วินาทีโดยพิจารณาจากความหน่วงแฝงในการหมุน ขนาดบล็อกมีผลกระทบน้อยที่สุดเมื่อรอ 1/2 การปฏิวัติเพื่อให้ดิสก์อยู่ในตำแหน่งที่ถูกต้องทำให้เกิดปัญหาอย่างอื่น

btw - iowait เป็นหนึ่งในการวัดที่เข้าใจผิดมากที่สุด มันไม่มีอะไรเกี่ยวข้องกับ cpu load มันแค่หมายความว่า cpu ไม่ได้ทำอะไรอย่างอื่นในขณะที่ I / O กำลังเกิดขึ้น ในความเป็นจริงถ้าคุณอยู่ที่ 100% iowait นั่นหมายความว่าคุณว่างเปล่า 100%!

-เครื่องหมาย