आयोस्टैट और ग्नूप्लोट के साथ प्रोफाइल फाइल सिस्टम लोड - शौकिया नोट्स

अक्सर काम "क्षेत्र में" उपयोगिताओं की अत्यंत दुर्लभ सूची की उपस्थिति में ग्राहक की वेबसाइट पर जानकारी के संग्रह और विश्लेषण की आवश्यकता होती है। विशेष रूप से, दिन के दौरान इनपुट-आउटपुट सिस्टम के उपयोग के बारे में जानकारी एकत्र करने के लिए।

लेख में मैं यह दिखाने की कोशिश करूंगा कि कैसे, केवल आईओस्टाट और ग्नूप्लोट होने पर, आप सिस्टम का विश्लेषण करने की कोशिश कर सकते हैं और क्या निष्कर्ष निकाला जा सकता है।

मैं विषय का गहन ज्ञान और शर्तों का सटीक उपयोग करने का दिखावा नहीं करता। इसके अलावा, मैं "साधारण" भाषा में बात करने की कोशिश करूँगा और शब्दों में जल्दबाज़ी नहीं करूँगा।

नीचे वर्णित सब कुछ अनुभव, गलतियों, गुगली, धूम्रपान मन और अन्य का परिणाम है

छोटा सा शैक्षिक कार्यक्रम

भंडारण के संदर्भ में I / O प्रणाली के प्रदर्शन के मूल्यांकन के संदर्भ में, कई विशेषताएं हैं:

• थ्रूपुट (प्रति सेकंड बाइट्स) - अधिकतम रैखिक गति जिसके साथ डिवाइस लिखता है या एक पढ़ता है, लेकिन एक बहुत बड़ी फ़ाइल।
• IOPS (संचालन प्रति सेकंड) - डिवाइस को भेजे गए अनुरोधों की संख्या। यह बड़ी संख्या में छोटी फ़ाइलों के साथ गति है।
• प्रसंस्करण समय (मिलीसेकंड) - एक I / O अनुरोध को औसतन संसाधित करने के लिए लगने वाला समय, जिसमें एक कतार में प्रतीक्षा करना शामिल है, और सबसे विशिष्ट प्रतीक्षा है, क्योंकि यह लोड पर निर्भर करता है, और अनुरोध के आकार पर नहीं। इस समय जितना अधिक होगा, एक आवेदन अनुरोध के लिए सिस्टम की प्रतिक्रिया धीमी हो जाती है, लेकिन बाकी एप्लिकेशन सिद्धांत रूप में प्रभावित नहीं होते हैं।
• डाउनलोड (प्रतिशत) - I / O पर सिस्टम लोड का एक अनुमान। 100% के करीब मूल्यों पर, सिस्टम "उठता है", सभी अनुप्रयोगों सहित। प्रोसेसर iowait पर जाते हैं, और ऐसी प्रक्रियाएं जो I / O चाहते हैं [डिस्क] स्लीप पर जाएं

यह समझा जाना चाहिए कि इनमें से कोई भी पैरामीटर फाइल सिस्टम के उपयोग की पूरी रूपरेखा नहीं दे सकता है। फ़ाइल सबसिस्टम के "क्लीन" ऑपरेशन को देखना और मूल्यांकन करना मुश्किल है, यदि केवल इसलिए कि इसके काम के ढेर में विभिन्न कैश हैं: डिस्क बफर, RAID नियंत्रक कैश, सिस्टम कैश। तदनुसार, अधिक या कम अतिरिक्त आंकड़े केवल पीक लोड के करीब प्राप्त किए जा सकते हैं। और भंडारण प्रणालियों के उचित परीक्षण का विषय, परिणामों की तुलना और मूल्यांकन करना आमतौर पर एक प्रतिज्ञा क्षेत्र नहीं है और आप शोध प्रबंध लिख सकते हैं।

मूलभूत विशेषताएँ

चूंकि निरपेक्ष संख्याओं को मापना आम तौर पर बहुत आभारी नहीं है, इसलिए मैं किसी तरह के आधार पर उनके मूल्य का मूल्यांकन करना पसंद करता हूं, और उसके बाद पहले से ही कुछ अन्य उपायों का उपयोग करता हूं। इसके अलावा, डीबीएमएस के साथ अनुभव यह संकेत देता है कि यह मूल्य नहीं हैं जो तुलना करने लायक हैं, लेकिन उनके आदेश।
इस तरह के आधार के लिए, मैंने अपने लिए निम्न आंकड़े लिए:
औसत सर्वर हार्ड ड्राइव 10 हजार क्रांतियों प्रति सेकंड है, एसएएस के माध्यम से एक सक्षम RAID नियंत्रक (बैटरी पर कैश के साथ) से जुड़ा हुआ है:

• अनुक्रमिक पहुँच के लिए प्रति सेकंड लगभग 300 मेगाबाइट का थ्रूपुट है
• लगभग 150 iops देता है (तोते में)
• 10 एमएस के आदेश के अनुरोध के प्रसंस्करण के समय पर

यदि यह सब RAID में रहता है, तो, छापे के प्रकार के आधार पर, संख्या गुणा या डिस्क की संख्या से विभाजित होती है। उदाहरण के लिए: RAID 1 + 0 में 4 डिस्क सभी चार डिस्क के कुल iops को दिखाना चाहिए।

यदि परीक्षण दिखाते हैं कि सिस्टम काम कर रहा है, तो लगभग इन नंबरों को दे रहा है, तो परीक्षण के दौरान किसी के पास "समायोजित" नहीं है, कोई चमत्कार नहीं है और आप काम कर सकते हैं। अन्यथा, आपको पहले यह पता लगाना चाहिए कि हार्डवेयर में क्या गड़बड़ है (शायद RAID ठीक हो रहा है या पेंच डालना है)।

मूल रूप से, मैं स्टोरेज सिस्टम के साथ काम करने की प्रभावशीलता और डीबीएमएस और हमारी सॉफ्टवेयर सेटिंग्स के प्रभाव का मूल्यांकन करने के लिए परीक्षण परिणामों का उपयोग करता हूं, साथ ही वे इसका उपयोग कैसे करते हैं, साथ ही डीबीएमएस समस्याओं का त्वरित निदान भी करते हैं।

माप

ट्रेनिंग

इसके साथ शुरू करने के लिए, यह समझने के लिए कि अनुभाग क्या प्रश्न हैं, df -hl रखना बुद्धिमानी है।

# df -hl Filesystem Size Used Avail Use% Mounted on /dev/sda1 4.0G 3.9G 0 100% / /dev/sda7 102G 94G 2.7G 98% /SQL /dev/sda6 1012M 307M 654M 32% /var /dev/sda2 3.0G 69M 2.8G 3% /tmp /dev/sda5 34G 24G 8.8G 73% /ARCHIVE tmpfs 4.0G 26M 3.9G 1% /dev/shm 

वैसे, यह याद रखना उपयोगी है कि स्वैप किन वर्गों में स्थित है।

यह अच्छा होगा यदि भौतिक उपकरण को प्रत्येक घटक के लिए अलग-अलग तार्किक विभाजन में विभाजित किया जाए। इस तरह हम प्रत्येक विस्फोट हुए घटक के लिए I / O उपयोग प्रोफ़ाइल का मूल्यांकन कर सकते हैं।

देख

अन्य उपयोगिताओं के विपरीत, iostat समय के आधार पर लॉगिंग के लिए बहुत अनुकूल नहीं है। खैर, कुछ नहीं, मदद करने के लिए जाग।

लॉग फ़ाइल पाने के लिए लाइन:

 iostat -xk -t 10 | awk '// {print strftime("%Y-%m-%d %H:%M:%S"),$0}' >> iostat.log & 

स्वाभाविक रूप से, आपको इसे स्क्रीन में चलाने की आवश्यकता है।

आपको -t 10 पैरामीटर पर ध्यान देना चाहिए। यह अंतराल है जिसके लिए मान औसत हैं और सेकंड में "औसत" की गणना की जाती है।

यदि मान बहुत छोटा है, तो चार्ट पर अतिरिक्त चोटियां और वृद्धि होगी। यदि यह बहुत बड़ा है, तो महत्वपूर्ण चोटियां ध्यान देने योग्य नहीं होंगी। मेरी राय में, 3-10 सेकंड का अंतराल इष्टतम है।

हमारा लॉग दर्ज करना कुछ इस तरह होगा:

 iostat -xk -t 10 | awk '// {print strftime("%Y-%m-%d %H:%M:%S"),$0}' 2013-01-14 11:31:04 Linux 2.6.32.32-m4.x86_64 (localhost.localdomain) 01/14/2013 2013-01-14 11:31:04 2013-01-14 11:31:04 Time: 11:31:04 AM 2013-01-14 11:31:04 avg-cpu: %user %nice %system %iowait %steal %idle 2013-01-14 11:31:04 0.67 0.00 1.02 1.11 0.00 97.20 2013-01-14 11:31:04 2013-01-14 11:31:04 Device: rrqm/s wrqm/sr/sw/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util 2013-01-14 11:31:04 sda 20.70 47.44 0.91 12.01 26.18 237.91 40.89 2.35 181.49 7.76 10.03 2013-01-14 11:31:04 sda1 0.00 0.83 0.08 0.67 0.94 6.00 18.47 0.05 61.99 15.81 1.19 2013-01-14 11:31:04 sda2 0.00 0.24 0.00 0.01 0.00 1.00 173.76 0.01 533.13 45.98 0.05 2013-01-14 11:31:04 sda3 0.00 0.00 0.00 0.00 0.01 0.02 120.95 0.00 33.78 25.52 0.00 2013-01-14 11:31:04 sda4 0.00 0.00 0.00 0.00 0.00 0.00 2.00 0.00 72.00 72.00 0.00 2013-01-14 11:31:04 sda5 7.45 2.07 0.18 1.17 3.82 12.99 24.88 0.06 41.68 13.86 1.87 2013-01-14 11:31:04 sda6 0.00 0.15 0.00 0.28 0.11 1.72 12.85 0.01 40.63 18.86 0.54 2013-01-14 11:31:04 sda7 13.24 44.15 0.65 9.87 21.29 216.18 45.16 2.23 211.42 7.91 8.32 2013-01-14 11:31:04 2013-01-14 11:31:14 Time: 11:31:14 AM 2013-01-14 11:31:14 avg-cpu: %user %nice %system %iowait %steal %idle 2013-01-14 11:31:14 0.61 0.00 1.06 1.20 0.00 97.12 2013-01-14 11:31:14 2013-01-14 11:31:14 Device: rrqm/s wrqm/sr/sw/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util 2013-01-14 11:31:14 sda 0.00 45.40 0.00 10.50 0.00 219.20 41.75 1.69 156.43 8.30 8.72 2013-01-14 11:31:14 sda1 0.00 0.80 0.00 0.30 0.00 4.40 29.33 0.01 25.33 25.33 0.76 2013-01-14 11:31:14 sda2 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 2013-01-14 11:31:14 sda3 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 2013-01-14 11:31:14 sda4 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 2013-01-14 11:31:14 sda5 0.00 1.30 0.00 1.00 0.00 9.20 18.40 0.03 27.80 8.10 0.81 2013-01-14 11:31:14 sda6 0.00 0.70 0.00 1.10 0.00 7.20 13.09 0.02 18.55 10.64 1.17 2013-01-14 11:31:14 sda7 0.00 42.60 0.00 8.10 0.00 198.40 48.99 1.63 195.89 8.15 6.60 

पहला ब्लॉक शुरुआत के क्षण से ऑपरेशन की अवधि के लिए माप है। बाकी निर्दिष्ट अंतराल के दौरान।

हम इसे एक निश्चित अंतराल पर शुरू करते हैं (उदाहरण के लिए, कुछ दिनों के लिए, और फिर हम आपको लॉग भेजने के लिए कहते हैं।

के विश्लेषण

भला, ऐसी संख्याओं को हम क्या कह सकते हैं?

सबसे पहले, अंतिम कॉलम% उपयोग पर ध्यान दें। यदि केवल इसलिए कि उपयोगकर्ता के लिए इस पैरामीटर (90% -100%) का बड़ा मूल्य "सर्वर हैंग होता है।" हमने 9% से कम sda लोड किया है। सामान्य। और मूल रूप से sda7 (SQL) अनुभाग।

आगे लिखें / पढ़ें मापदंडों:

1. कॉलम थ्रूपुट आरकेबी / एस, डब्ल्यूकेबी / एस। हम 219 KB / s लिखते हैं
2. iops r / s, w / s कॉलम - प्रति सेकंड 10.5 प्रश्न
3. अनुरोध प्रसंस्करण समय: प्रतीक्षा - 156 एमएस, जिनमें से svctm का वास्तविक निष्पादन 8 एमएस है

यह किस बारे में बात कर रहा है:
डिस्क लोड नहीं है, संख्या बड़ी नहीं है। लेकिन अनुरोध 200ms कतार में हैं, समय स्वीकार्य है, लेकिन "पहली बार यह विभाजित हो जाएगा" के साथ, सबसिस्टम ही घटिया है। हालांकि इसे असमान रूप से कहना असंभव है? क्योंकि फिर से डिस्क यहां भारी नहीं है और कतार से डेटा भेजने के लिए जल्दी में नहीं है।

यह भी उपयोगी है: rrqm / s, wrqm / s वास्तव में उन अनुरोधों की संख्या है जिन्हें अनुप्रयोगों को निष्पादित करने के लिए कहा गया था, लेकिन सिस्टम औसत एवार्क-एसज़ बाइट्स पर उन्हें ब्लॉक में संयोजित करने में सक्षम था।

ये आंकड़े आवेदन को अनुकूलित करने में मदद करेंगे:

• यदि आप 100,500 फाइलें खोलते हैं, तो बेतरतीब ढंग से खुली फाइलों पर कूदना शुरू कर दें और अन्य ज्यादतियां करें, सिस्टम कैश को काट लें - r / s, w / s rrqm / s और wrqm / s पर चले जाएंगे, और avgrq-sz क्रैश हो जाएगा। यह एक शुद्ध यादृच्छिक अभिगम स्थिति है - सबसे धीमी डिस्क उपयोग परिदृश्य।
• और अगर सब कुछ सुसंगत है, तो वे एकता के लिए प्रयास करेंगे (या शून्य के लिए), और एग्रिक-एसज़ बढ़ेगा। अंतराल के लिए एकमात्र अनुरोध अनुक्रमिक एक्सेस है - सबसे तेज़ डिस्क उपयोग परिदृश्य।
  

यह स्पष्ट है कि लगातार काम करना मुश्किल है, और अक्सर असंभव है, लेकिन इन संख्याओं की तुलना करके आप मूल्यांकन कर सकते हैं कि क्या इस पर लोड में सुधार हुआ या डिस्क के साथ काम करने के तर्क में बदलाव खराब हो गया।

ग्राफिक्स

वास्तव में आंखों से लॉग देखना एक धन्यवाद का काम है। इसलिए, मैंने बैश और ग्नुप्लॉट के कुछ "स्क्रिप्ट्स" लिखे और थोड़ा सा लॉग और ग्राफिक्स का निर्माण किया।

1 पैरामीटर के साथ एक उपकरण के लिए एक ग्राफ प्लॉट करना

 #!/bin/bash #echo "usage: $0 <iostat.log> <disk name> <out.png> <title> <yaxis-title> <column1> <title1> echo "procesing $1 for device $2, plotting $3 ($4 - $7)" cat $1 | grep "$2 " > dat.dat gnuplot <<_EOF_ set terminal png set output "$3" set title "$4" set xdata time set timefmt "%Y-%m-%d %H:%M:%S" set format x "%H:%M\n%d/%m" set xtics nomirror scale 3,2 set ylabel "$5" set samples 60 plot "dat.dat" using 1:$6 title "$7" with impulses, \ "dat.dat" using 1:$6 title "$7 avg" smooth bezier lw 2 _EOF_ rm dat.dat 

और 2 मन मापदंडों में एक डिवाइस के लिए एक ही ग्राफ:

 #!/bin/bash echo "procesing $1 for device $2, plotting $3 ($4 - $7, $9)" cat $1 | grep "$2 " > dat.dat gnuplot <<_EOF_ set terminal png set output "$3" set title "$4" set xdata time set timefmt "%Y-%m-%d %H:%M:%S" set format x "%H:%M\n%d/%m" set xtics nomirror scale 3,2 set ylabel "$5" set samples 10 plot "dat.dat" using 1:$6 title "$7" with lines, \ "dat.dat" using 1:$8 title "$9" with lines _EOF_ rm dat.dat 

खैर, चूंकि बहुत सारे उपकरण हैं, और कई सर्वर हैं, और मैं कलम के साथ आलस्य शुरू कर सकता हूं, मैंने कुछ और आदिम पटकथाएं लिखी हैं: plot_info.sh

 #!/bin/bash echo "usage: $0 <n> <flitle> <title> <y-axis> <column1> <column-title> <column2> <column-title>" echo "$0 2 rw 'Read/write iops per second' 'iops' 4 'read request/s' 5 'write request/s'" #/dev/cciss/c0d0p1 20G 12G 7.2G 61% / #/dev/cciss/c0d0p6 476G 213G 239G 48% /ARCHIVE #/dev/cciss/c0d0p5 9.7G 264M 8.9G 3% /var #/dev/cciss/c0d0p3 9.7G 167M 9.0G 2% /TMP #/dev/cciss/c0d1p1 559G 39G 521G 7% /SQL #/dev/cciss/c0d2p2 1020G 320G 701G 32% /SQL/file #/dev/cciss/c0d2p1 98G 1.9G 96G 2% /SQL/pgsql/data/pg_xlog ./graph$1.sh ./log201.txt c0d0p2 201/c0d0p2.swap.$2.png "swap $3" "$4" "$5" "$6" "$7" "$8" ./graph$1.sh ./log201.txt c0d0p3 201/c0d0p3.tmp.$2.png "/TMP $3" "$4" "$5" "$6" "$7" "$8" ./graph$1.sh ./log201.txt c0d1p1 201/c0d1p1.sql.$2.png "/SQL $3" "$4" "$5" "$6" "$7" "$8" ./graph$1.sh ./log201.txt c0d2p1 201/c0d2p1.pg_xlog.$2.png "pg_xlog $3" "$4" "$5" "$6" "$7" "$8" ./graph$1.sh ./log201.txt c0d1 201/dev.c0d1-sql.$2.png "dev:/SQL $3" "$4" "$5" "$6" "$7" "$8" ./graph$1.sh ./log201.txt c0d2 201/dev.c0d2-xlog_file.$2.png "dev:pg_xlog+file $3" "$4" "$5" "$6" "$7" "$8" 

और कार्य

 #!/bin/bash ./plot_info.sh 3 iops_load 'Estimated IOPS' 'iops_limit' '(100*($7+$6)/$14)' 'iops' ./plot_info.sh 0 wrratio 'Write percent' 'wratio' '($9*100/($10+$9))' '%' ./plot_info.sh 0 qwaitratio 'Queue wait ratio' 'qwaitratio' '($13*100/$12)' '%' ./plot_info.sh 2 rwqm 'Request merged and queued to device' 'rqm/s' 4 'read rqm/s' 5 'write rqm/s' ./plot_info.sh 2 request 'Request issued to device' 'requests' 6 'r/s' 7 'w/s' ./plot_info.sh 2 rwspeed 'Read/write speed (kB per sec)' 'speed' 8 'read kB/s' 9 'write kB/s' ./plot_info.sh 1 rsize 'Average request size' 'avgrq-sz' '($10*4)' 'kB' ./plot_info.sh 1 qsize 'Average query size' 'avgqu-sz' 11 'queries' ./plot_info.sh 2 await 'Average request servicing time' 'await' "'12'" 'waiting msec' 13 'servicing msec' ./plot_info.sh 1 util 'Bandwidth utilization' '%util' 14 '%' ./plot_info.sh 1 iops 'Average IOPS' 'iops' "'7+6'" 'iops' 

कोड के लिए, मैं आपको इसे किक न करने के लिए कहता हूं, यह जल्दी से और घुटने पर काम करने के लिए लिखा गया था (जिसके लिए स्क्रिप्ट वास्तव में स्मार्ट लोगों द्वारा आविष्कार किया गया था)।

नतीजतन, हमें अच्छे ग्राफिक्स मिलते हैं।

सारांश

"सफल कहानियों" के एक जोड़े के सारांश के रूप में

आमतौर पर, उपयोगकर्ता के पास केवल एक लक्षण होता है: सब कुछ धीमा हो जाता है। नीचे मैं इस बात का उदाहरण दूंगा कि समस्या की पहचान करने में इओसैट लॉग के विश्लेषण ने कैसे मदद की, या संकेत दिया कि समस्या डिस्क में नहीं है।

पहली कहानी

Iostat ने असामान्य रूप से उच्च आरकेबी / एस मूल्यों को देखा, जब सबसे सरल प्रश्नों का प्रदर्शन किया, जिसमें लिमिट 1 (दसियों और सैकड़ों मेगाबाइट) के साथ प्रश्न शामिल हैं - हम स्पष्ट रूप से आवश्यक से अधिक पढ़ते हैं।
इससे हम अंततः दिखा पाए कि ऑटो-वैक्यूम काम नहीं करता था (हालाँकि यह शुरू हुआ था)। एक और वैक्यूम लॉग से पता चला कि max_fsm_page आवश्यकता से कम परिमाण के दो आदेश हैं।

दूसरी कहानी

लगभग 60 सेकंड की लंबी लेनदेन प्रतिबद्धता जिसमें केवल एक दर्जन डीडीएल अनुरोध हैं। सभी ने उच्च "पृष्ठभूमि" भार पर पाप किया, जैसे कि यह धीमा हो जाता है। लेकिन iostat ने हर संभव तरीके से दिखाया कि इस समय डिस्क पर कोई अतिरिक्त विसंगति नहीं थी। नतीजतन, बिंदु अप्रयुक्त के एक बड़ी संख्या (पूल) के साथ जुड़े "छोटे" कैंट पोस्टग्रेक्यूएल 8.3 डीबीएमएस में है ...

क्या यह सब के बारे में थोड़ा सा है।

ऐसा हुआ कि हम जो उत्पाद विकसित कर रहे हैं, उसमें पोस्टग्रेसीक्यू डीबीएमएस पर आधारित कुछ प्रकार के भंडारण शामिल हैं। और यह डेटाबेस डीबीए से किसी भी पर्यवेक्षण के बिना रहता है, और हमारे समर्थन को इस तक पहुंच नहीं दी गई है। इस डेटाबेस में पढ़ने के लिए कुछ ग्राहक हैं - कुछ दर्जन। लेकिन रिकॉर्डिंग के लिए क्लाइंट, हालांकि कई नहीं (सैकड़ों तक), वे केवल 24/7 लिखते हैं जब प्रति सेकंड सैकड़ों रिकॉर्ड होते हैं, और जब एक या दो हजार। ठीक है, जैसा कि महान मर्फी को निहारा गया है - सब कुछ हमेशा एक परीक्षण प्रयोगशाला में सिंथेटिक्स पर काम करता है, लेकिन वास्तविक डेटा पर क्षेत्र में, "सब कुछ बहुत धीमा है।"

नतीजतन, कार्य गलत हाथों से फोन द्वारा कॉम्प्लेक्स के संचालन पर जानकारी एकत्र करने और यह पता लगाने के लिए उठता है: इससे क्या गायब है। और ये हाथ आमतौर पर अकुशल होते हैं, पुट्टी और विनएससीपी को अधिक से अधिक चलाते हैं, किसी प्रकार की स्क्रिप्ट, लॉग भेजते हैं। आप अधिक पर भरोसा नहीं कर सकते

एक और सवाल जटिल जटिल है, कोई अतिरिक्त लोहा नहीं है। बेशक, आप अतिरिक्त सॉफ़्टवेयर स्थापित कर सकते हैं, लेकिन हम सभी समझते हैं कि मुफ्त सॉफ्टवेयर भी मुफ्त नहीं है, और ग्राहक अतिरिक्त स्थापना, कॉन्फ़िगरेशन और समर्थन के लिए भुगतान नहीं करना चाहता है। और फिर, सिस्टम में अतिरिक्त घटक बढ़ी हुई विश्वसनीयता में योगदान नहीं करता है।

परिणामस्वरूप, हमारे पास:
उस पर रहने वाले PostgreSQL DBMS के साथ HP DL380G7 स्तर का एक सर्वर और C ++ में लिखे गए सभी प्रकार के क्लाइंट्स का एक बंधन।
ट्रंच किए गए फेडोरा या सेंटोस वितरण पर आधारित एक ऑपरेटिंग सिस्टम।
एक दर्जन एसएएस शिकंजा के साथ एक सामान्य RAID नियंत्रक पर आधारित भंडारण।
उपयोगिताओं में से, केवल बहुत ही न्यूनतम उपलब्ध है, जिसमें iostat और gnuplot शामिल हैं।