Server

เรื่องเล่าจาก CAT ไฟดับ เมื่อวันที่ 30 พฤศจิกายน 2556

by

เพิ่งจะว่างๆ นั่งเคลียร์สมองเพื่อมาเล่าเหตุการณ์แบบสรุปๆ ให้ได้อ่านกัน

อ่านข้อมูลเพิ่มเติมเรื่องนี้ได้ที่ ทำไมตึก กสท บางรัก ไฟดับแล้วทำให้ระบบเน็ตป่วนทั้งประเทศ เป็นข้อมูลความรู้เพิ่มเติมครับ

ต้องบอกก่อนว่า ระบบที่ผมดูแลมันไม่ได้เยอะอะไรหรอก Server ยี่ห้อ Dell อยู่ 7 ตัวใน CAT บางรัก วางใน IDC เจ้าหนึ่ง ไม่ใช่เครื่องผมโดยตรง มูลค่าเครื่องทั้งหมดก็หลายแสน ระบบและข้อมูลภายในบริการลูกค้าเยอะพอตัวเลย

โดยไฟดับในวันที่ 30 พฤศจิกายน 2556 ที่ผ่านมานั้น ดับไปประมาณ 6 ชั่วโมง เสียหายไปรวมเกือบ 5 แสนบาท โดยประเมิณค่าเสียหายจาก transaction เก่าในวันเดียวกันของอาทิตย์ก่อนๆ (เก็บเงินจากใคร!!!)

WP_20131123_22_54_23_Pro

การตรวจสอบการ up/down time ของระบบที่ดูแลผมใช้แบบ International และ Domestic connection คือส่วนของ International นั้นผมใช้ uptimerobot ในการตรวจสอบการมีอยู่ของระบบจากภายนอกประเทศ ส่วน Domestic จะติดตั้งและทำงานผ่าน nagios ซึ่งทำงานภายใน local switch ที่อยู่ใน IDC เลย เพราะฉะนั้น ถ้ามีปัญหาระบบแจ้งเตือนทั้งสองจุดจะแจ้งพร้อมกัน (หรือใกล้เคียงกัน) แต่ระบบทั้ง 2 ส่วนนั้น มีการวิ่งตรวจสอบไขว่กัน เพราะระบบ nagios  ที่ติดตั้งนั้น ได้เช็คระบบที่ไว้ที่ต่างประเทศด้วย ตามแผนภาพด้านล่างด้วย

image

แต่ในวันนั้น ระบบ uptimerobot แจ้งเตือน เวลา 15:20 และค่อยๆ ไล่ส่งการแจ้งเตือนมาทุกเครื่องที่อยู่ในตึก CAT บางรัก (ส่งมาเป็นสิบฉบับเลย)

โอเค ปรกติ link ของ International ในตึก CAT บางรัก อาจมีปัญหาบ้าง เพราะผมได้แจ้งเตือนแบบนี้บ่อย เพราะ link ของ International ล่ม แต่รอบนี้แปลกมากๆ เพราะในทางกลับกัน ส่วนของ nagios  มันก็ต้องแจ้งเตือนว่า Server ที่อยู่เมืองนอกมันล่มด้วย เพราะวิ่งออกไป International ไม่ได้ แต่รอบนี้ไม่มี uptimerebot ส่งเพียงฝ่ายเดียวเท่านั้น

Uptime Robot [email protected]

ส. 30/11/2556 15:20

Hi,
The monitor xxx – HTTP (xxx)  is currently DOWN (Connection Timeout).

Uptime Robot will alert you when it is back up.

Cheers,
Uptime Robot
http://www.uptimerobot.com
http://twitter.com/uptimerobot
(sent from new engine)

เวลาประมาณ 15:25 ผมเลยกดเข้าเว็บที่ดูแลอยู่ ทุก link ทุก IP ทุก port ที่สามารถจะเข้าได้ แต่ทุกอย่างไร้การตอบสนอง…

Read more

SSD กับงาน Database Server

by

ใช้ SSD Vertex 4 (SATA3 ทำงานบน SATA2) ขนาด 60GB ทั้งหมด 2 ตัวบน Production อยู่ 2 รอบบ ตัวแรกระบบ Frontend ทำงานตลอดเวลา 24 ชั่วโมงโหลดข้อมูลบน Database MySQL ขนาด transaction 30-100 queries/s แบบ ACID Model ตลอด (เป็น transaction เรื่องเงินเลยต้องมี locking ระดับ row ด้วย) แต่พังในเวลาประมาณ 3 เดือน และตอนนี้ SSD ตัวใหม่ก็ยังทำงานได้ดีอยู่ลุ้นๆ จะไปต่อได้แค่ไหน ส่วนอีกตัวทำงานมาแล้ว 6 เดือน ยังไม่มีปัญหาใดๆ ตัวนี้ทำงานที่ 500-600 queries/s แต่เป็น ISAM model ตลอด (ไม่มีการ locking ใดๆ) การทำใช้ SSD มาทำงานและแก้ไขปัญหาเรื่อง IOPS ของ database ช่วยให้งานที่อาจใช้เวลา 1-5 วินาที เสร็จสิ้นภายในเวลาหน่วย ms เท่านั้น ซึ่งคุ้มเสี่ยงที่จะใช้

คำถามคือระบบป้องกันทำอย่างไร? เพราะ SSD มีโอกาสเสียง่ายกว่า HHD อยู่แล้ว ซึ่งแก้ปัญหาด้วยการทำระบบด้านหลังอีกชุด โดยรัน VM ควบคู่ทั้งสองระบบ ซึ่งทำ Realtime backup แบบ Replication ที่ทำงานแบบ Event base ตลอดเวลาเพื่อคอย Backup ไว้อีกชุดและมีชุด VM อีกตัวทำหน้าที่ Daily backup แบบ Full Database อีก 1 ชุดสามารถรองรับการ downtime ได้ 99.9% per year ได้สบาย

โดยระบบเคย down เพราะ SSD พังและนำกลับมาอยู่ใน State ‘uptime’ ได้ในเวลาประมาณ 30 นาที ด้วยการกู้จาก Realtime backup มาใส่ในระบบที่ยังทำงานปรกติอีกระบบไปก่อน แล้วเข้าไปเปลี่ยน SSD ตัวใหม่เสร็จสิ้นใน 6 ชัวโมง (จากที่บอกไปด้านบน) อันนี้คือการแก้ไขปัญหานี้

ส่วนการแนวการแก้ไขปัญหาต่อไปในช่วงปีนี้ คือแผนการทำ HA ตัว Database Server เพิ่มเติม แต่ยัง LAB เรื่อง MySQL Cluster ว่าจะเอามาใช้อะไรได้บ้างและมีความเร็วเพียงพอหรือไม่ที่จะทำแบบนี้ หรือทำ RAID SSD ก็น่าสนใจเช่นกันคงต้อง LAB ต่อไปอีกสักพัก

แนะนำ zonomi บริการ DNS hosting ราคาไม่แพงแต่ประสิทธิภาพดี

by

แนะนำ DNS hosting เพราะจากที่ใช้มาต้องบอกว่า UI เรียบง่ายดี ถ้ารู้เรื่อง Domain Name System (DNS) zone file อยู่แล้วคงจะใช้งานไม่ยากมากนัก โดยรวมแล้วที่นี่ Update ตัว DNS รวดเร็วดี ใครอยากทดลองใช้ ก็มีแบบฟรีให้ โดยให้ 1 domain ใช้ได้ 10 records แต่ถ้ามากกว่านั้น ราคาต่อปีก็ไม่แพงจนเกินไป แต่ถ้าใช้ร่วมกับ google apps อาจไม่เพียงพอคงต้องจ่ายเพิ่มเป็นรายปี แต่ส่วนตัวใช้กับ domain อยู่ 17 ตัวก็เสียเดือนละ $2.55 แลกกับความง่ายและระบบ DNS แบบ Fully redundant, fault-tolerant, reliable name servers (ระหว่าง London, Dallas, New York และ Auckland) ทั้งหมด 4 ระบบ มีระบบ API สามารถเขียนระบบเชื่อมต่อทำ Dynamic DNS ได้ และ รองรับ pingability.com สำหรับทำ service monitor ต่างๆ ซึ่งถ้าใครต้องการใช้ DNS Server ที่เป็นระบบโดยไม่อยากทำเอง และแยกจาก Server บริการต่างหาก อย่างเช่น Web หรือ Mail ด้วย ส่วนตัวแล้วนั้น ดูจะถือว่าคุ้มค่ามากๆ

Zonomi – DNS hosting – Zonomi

ข้อเสนอการออกรุ่นใหญ่ของ Ubuntu อาจทำให้ต้องใช้แต่ LTS สำหรับงานด้าน Server

by

จากข่าว “Ubuntu พิจารณาปรับแผนออกรุ่นใหญ่เฉพาะ LTS และออกรุ่นย่อยให้ถี่กว่าเดิม”

โดยส่วนตัวก็ถือว่าดีในมุนของผู้ใช้งานทั่วไปมากกว่างานระบบ Server ที่ผมทำงานอยู่นะ

คือส่วนตัวใช้ Long Term Support (LTS) สำหรับงานด้าน Server เป็นหลัก และนานๆ ครั้งจะใช้ Interim Release (IR) กับงาน Server เพราะ LTS นั้นช่วยให้เราสามารถรัน App ที่พัฒนาได้ครบรอบ Software Support ได้ 18 เดือนแน่ๆ ซึ่งอย่างน้อยๆ ก็ไม่ทำให้ระบบต้องแก้ไขเรื่องเข้ากันไม่ได้กับระบบ OS โดยรวม แต่ถ้าต่อไปเป็น Rolling Release แทน Interim Release ก็อาจจะใช้แต่ LTS ล้วนๆ แทน ซึ่งก็ไม่แน่นะ ผมอาจจะเปลี่ยนใจมาใช้ Debian แทนก็ได้ เพราะ Rolling Release สำหรับงาน Server ดูจะเสี่ยงเกินไปหน่อย ขนาด 18 – 24 เดือนเปลี่ยน System ทีคนทำระบบหลายๆ คนยังร้องเลย ><”

มาดูกันว่า CPU execution time ของ Colocation Server, Virtual Private Server และ Cloud Virtual Machines มา benchmark กันจะเป็นอย่างไร

by

เอา Server ที่ใช้งานเอามาเทียบกันทั้งหมด 5 ตัวคือ

  • Dell PowerEdge 1425 – Intel Xeon 3.0 GHz Processor (64 Bit)
    ตัวนี้อายุเกือบๆ 6 ปีแล้ว แต่ยังทำงานได้ดีอยู่
  • Windows Azure Virtual Machines (VM) Extra Small (XS/S) – Virtual CPU 1Ghz Processor x 1 cores
    ตัวที่ให้บริการ blog นี้อยู่
  • VPS – Intel Virtual CPU 2.4Ghz x 2 cores
    เช่ามาใช้งานเฉพาะด้าน
  • Dell PowerEdge R410 – Intel Xeon E5620 2.40GHz Processor x 4 cores
    อายุใช้งานยังไม่ถึง 1 ปีดี
  • Dell PowerEdge R210 Server – Intel Xeon X3450 2.66Ghz Processor x 4 cores
    อายุใช้งานยังไม่ถึง 1 ปีดี

ตัวซอฟต์แวร์ที่ใช้ในการ benchmark คือ sysbench

คำสั่งที่ใช้คือ

sysbench --test=cpu --cpu-max-prime=20000 run

การรัน benchmark ใช้การทำงานเพียง 1 Thread เท่านั้น เพื่อทดสอบ process เพียงหน่วยประมวลผลเดียว เพื่อลดความได้เปรียบเสียเปรียบจาก CPU Core แต่เมื่อมี Core ของ CPU ที่มากก็สามารถรับโหลดได้เยอะขึ้นสำหรับซอฟต์แวร์ที่ทำงานแบบขนานได้

ผลการรันชุดคำสั่งทดสอบเป็นดังนี้

Server Info/CPU execution time
Dell PowerEdge 1425
– Intel Xeon 3.0 GHz Processor (64 Bit)		 78.9891s
Windows Azure
Virtual Machines (VM) Extra Small (XS/S)
AMD Opteron Processor 4171 HE 2.1GHz
– Virtual CPU 1Ghz Processor x 1 cores
–  Shared Core
Virtual Machines (VM) Small (S)
– Virtual CPU 1Ghz Processor x 1 cores
– Reserved Core		 45.9640s
(Shared Core – XS)

45.7989s
(Reserved Core – S)
VPS
– Intel Virtual CPU 2.4Ghz x 2 cores		 36.1133s
Dell PowerEdge R410
 – Intel Xeon E5620 2.40GHz Processor x 4 cores		 27.3706s
Dell PowerEdge R210 Server
– Intel Xeon X3450 2.66Ghz Processor x 4 cores		 24.5454s

* ตัวเลข execution time ยิ่งน้อยยิ่งเร็ว

จะเห็นได้ว่าความเร็วของการประมวลผลบน Windows Azure นั้นทำออกมาได้ดีกว่า Server เดี่ยวๆ เมื่อหลายปีก่อนพอสมควรเลย ลองตัดสินเอาเองว่าเราต้องการความเร็วในการประมวลผลเยอะเพียงใด และซอฟต์แวร์ที่ใช้เน้นการประมวลผลแบบขนานหรือไม่ ถ้าใช้การประมวลผลแบบขนาน เราสามารถเพิ่ม CPU Core บน VM ได้เรื่อยๆ ตามความต้องการเลยทีเดียว

ผลการทดสอบแบบละเอียด

Dell PowerEdge 1425
Intel Xeon Processor 3.0 GHz (64 Bit) x 1 cores

Maximum prime number checked in CPU test: 20000
Test execution summary:
total time:                          78.9891s
total number of events:              10000
total time taken by event execution: 78.9686
per-request statistics:
min:                                  5.72ms
avg:                                  7.90ms
max:                                 50.48ms
approx.  95 percentile:              14.34ms
Threads fairness:
events (avg/stddev):           10000.0000/0.00
execution time (avg/stddev):   78.9686/0.00

Windows Azure Virtual Machines (VM) Extra Small (XS/S)
AMD Opteron(tm) Processor 4171 HE 2.1GHz
Virtual CPU 1Ghz x 1 cores

Shared Core – XS
Maximum prime number checked in CPU test: 20000
Test execution summary:
total time:                          45.9640s
total number of events:              10000
total time taken by event execution: 45.9519
per-request statistics:
min:                                  4.42ms
avg:                                  4.60ms
max:                                 24.06ms
approx.  95 percentile:               4.68ms
Threads fairness:
events (avg/stddev):           10000.0000/0.00
execution time (avg/stddev):   45.9519/0.00

Reserved Core – S
Maximum prime number checked in CPU test: 20000
Test execution summary:
total time:                          45.7989s
total number of events:              10000
total time taken by event execution: 45.7871
per-request statistics:
min:                                  4.23ms
avg:                                  4.58ms
max:                                 21.47ms
approx.  95 percentile:               4.72ms
Threads fairness:
events (avg/stddev):           10000.0000/0.00
execution time (avg/stddev):   45.7871/0.00

 

My Private Client VPS
CPU Intel Virtual CPU 2.4Ghz x 2 cores

Maximum prime number checked in CPU test: 20000
Test execution summary:
total time:                          36.1133s
total number of events:              10000
total time taken by event execution: 36.1074
per-request statistics:
min:                                  3.00ms
avg:                                  3.61ms
max:                                 16.57ms
approx.  95 percentile:               4.22ms
Threads fairness:
events (avg/stddev):           10000.0000/0.00
execution time (avg/stddev):   36.1074/0.00

Dell PowerEdge R410
Intel(R) Xeon(R) E5620 2.40GHz

Maximum prime number checked in CPU test: 20000
Test execution summary:
total time:                          27.3706s
total number of events:              10000
total time taken by event execution: 27.3697
per-request statistics:
min:                                  2.69ms
avg:                                  2.74ms
max:                                  5.32ms
approx.  95 percentile:               2.77ms
Threads fairness:
events (avg/stddev):           10000.0000/0.00
execution time (avg/stddev):   27.3697/0.00

Dell PowerEdge R210 Server
Intel Xeon X3450 Processor

Maximum prime number checked in CPU test: 20000
Test execution summary:
total time:                          24.5454s
total number of events:              10000
total time taken by event execution: 24.5444
per-request statistics:
min:                                  2.45ms
avg:                                  2.45ms
max:                                  3.64ms
approx.  95 percentile:               2.45ms
Threads fairness:
events (avg/stddev):           10000.0000/0.00
execution time (avg/stddev):   24.5444/0.00