สืบเนื่องจาก entry ที่แล้ว
ก็เลยลองไปค้นๆ ข้อมูลเพิ่มเติมดูอีกหน่อยว่าเราลืมอะไรไปบ้าง
เพราะนึกได้ว่ายังไม่ได้ลองทำ MySQL Replicate เลย (ฮาๆ)
ประเด็นคือไม่รู้ว่ามันช้าที่ฐานข้อมูลรึเปล่า เพราะ debug ไม่เจอสาเหตุ
ก็เลยต้องลองทำเท่าที่ทำได้ไปก่อน

ขั้นต้นก็ต้องมี server 2 เครื่องขึ้นไปครับ
โดยสมมติเครื่องแรก ชื่อ web-slave
เครื่องที่สอง ชื่อ db-master

ก่อนอื่นมาที่เครื่อง web-slave สั่งติดตั้ง mysql server ตามนี้ครับ
* อ้างอิง Fedora 8 ครอบคลุม Fedora 4 – 9, CentOS 5.x รวมถึงสาย Redhat ทั้งหมดครับ

# yum install mysql-server

เสร็จแล้วเปิดแฟ้ม /etc/my.cnf เพิ่มเติมข้อมูลต่อไปนี้ครับ

server-id=2
master-host=0000ff;">10.0.0.2
master-port=3306
master-user=ff0000;">replicate
master-password=ff0000;">slavepassword
master-connect-retry=30
replicate-wild-do-table= %.%
report-host=008000;">10.0.0.1

(มันมาอีกละ สีฟ้าแดงเขียวนี่)
แก้ ip อะไรพวกนี้ให้ถูกนะครับ แล้วแก้ตัวแดงๆ ด้วย ตามที่ตั้งค่า

เครื่องนี้เสร็จและ กลับไปที่เครื่อง db-master ต่อ ก่อนอื่นต้องตั้งค่า username / password ก่อนครับ
โดยเข้าไปใน mysql query console (หรือที่ไหนก็ได้ที่สามารถตั้ง user ได้) แล้วรัน query ต่อไปนี้

mysql> GRANT REPLICATION SLAVE ON *.*
TO ‘ff0000;">replicate‘@’008000;">10.0.0.1‘ IDENTIFIED BY ‘ff0000;">slavepassword‘;

เสร็จแล้วออกมาสั่ง stop service mysql ได้เลยครับ แล้วก็แก้แฟ้ม /etc/my.cnf อีกนิดหน่อย ตามนี้ครับ

log-bin=ff00ff;">mysql-bin
server-id=1
innodb_flush_log_at_trx_commit=1
sync_binlog=1
expire_logs_days=ff00ff;">3
max_binlog_size=ff00ff;">50M

ตรงนี้ปรับค่าตามความเหมาะสมนะครับ แล้วแต่ว่าจะเก็บ log กี่วันยังไง
โดยบรรทัดแรกสุดจะเป็น path + ชื่อแฟ้มที่ใช้เก็บ log (สามารถใส่ full path ได้ครับ เช่น /var/log/mysqld/binlog)
แล้วก็ย้ำว่าควรจะใส่ option สองบรรทัดด้านล่าง เพื่อป้องกัน hdd เต็ม (ฮา)
เคยเจอมาแล้วครับ เก็บ log เพลินไปหน่อย เศร้าเลย

ต่อจากนี้ก็ copy ข้อมูลจาก db-master ไปยังเครื่อง web-slave ครับ
ถ้าใน fedora/centos default install ก็อยู่ใน /var/lib/mysql
สั่ง tar ไปทั้ง folder เลยก็ยังไหวครับ (แต่ข้อแม้คือต้องเป็น mysql version เดียวกันนะ)

จากนั้นก็สั่ง service mysqld start ทั้งสองเครื่อง
แล้ว connect เข้า mysql ของเครื่อง db-master สั่ง query ต่อไปนี้ครับ

mysql> FLUSH TABLES WITH READ LOCK;

แล้วก็ connect เข้า mysql ของเครื่อง web-slave สั่ง query ต่อไปนี้ครับ

mysql> START SLAVE;

เท่านี้ก็เรียบร้อย ทีนี้ก็รอดูผลงาน… ถ้าเวิร์กจะเอาไปใส่เว็บ bitthai ด้วย (ฮาๆ)

โจทย์มีมาให้ค่อนข้าง… เอ่อ… ระดับนึงละครับ
server 2 เครื่อง เครื่องแรก Core 2 Duo E6600 / RAM 3 GB
เครื่องที่สอง Core 2 Quad Q6xxx อะไรซักอย่าง จำรุ่นไม่ได้ / RAM 3GB

จะบอกว่ามันใช้งานหนักเอามากๆ
งานนี้ก็เลยต้องทดลองมันสารพัดวิธีเลยครับ

เริ่มจาก level แรกสุด apache + squid reverse proxy ไม่ผ่านเลยครับ (load avg 50.xx)
level ที่สอง เพิ่ม DNS Round Robin เข้าช่วย เอาเครื่อง DB มาช่วยรันเว็บด้วย ก็ยังไม่ผ่าน แต่ดีขึ้นหน่อยนึง (load เหลือ 30.xx)
level ที่สาม ลง memcache ช่วยระบบ session + SMF memcache ก็ไม่ผ่านอยู่ดี แต่ดีขึ้นใช้ได้ (load เหลือ ~25.xx)

level สุดท้าย เลิกใช้ apache ลบ squid ทิ้ง แล้วลง lighttpd 1.4 + mod fastcgi แทน
load average ลดลงมาเหลือประมาณ 5-6 แต่ page generation time ก็ยังไม่ค่อยจะน่าพอใจ
แบบว่าหน้า index พี่ซัดไป 300 KB เยอะโคดเลย

งานนี้ขอเวลาไปสัปดาห์นึง ต้องนั่งเฝ้าอีก เห้อ… ไหนจะงานรับน้องด้วย งิดๆๆๆ

เพิ่มเติมทางเทคนิค:

NFS service บน Fedora 7 เป็นต้นมา มีการเปลี่ยนแปลงชื่อ service นิดๆ หน่อยๆ
ทำเอางงกันใช้ได้ (ฮาๆ) ตามรายการต่อไปนี้ครับ

• nfs ยังคงสภาพเดิม คำสั่งเดิมได้เลย
• portmap เปลี่ยนชื่อไปเป็น rpcbind
• เพิ่มเติม service nfslock ไว้ทำ nfs remote lock เวลาต้องการ lock access file ต่างๆ

ขั้นตอนการติดตั้ง nfs บน Fedora 8 ง่ายมากจนน่าตกใจ ดังนี้ครับ

# yum install nfs-utils

จบเลย คำสั่งเดียวสั้นๆ ง่ายๆ เลย
เสร็จแล้วก็ตั้งค่าให้รันตั้งแต่เริ่มเปิดเครื่อง (สำหรับเครื่อง nfs server เท่านั้น)

# chkconfig nfs on
# chkconfig nfslock on
# chkconfig rpcbind on

แล้วแก้แฟ้ม /etc/exports ตามคู่มือ (รายละเอียดค่อนข้างเยอะ ไว้ค่อยสาธยาย ง่วงมาก)
พร้อมด้วยการแก้ /etc/hosts.allow เพื่อเพิ่มความปลอดภัยให้แก่ nfs server
แก้เสร็จแล้วก็สั่ง start service ทั้งสามตัวได้เลย ตามลำดับต่อไปนี้

# service rpcbind start
# service nfs start
# service nfslock start

จากนั้นไปที่เครื่อง client ที่จะ mount nfs partition แล้วทดลองสั่งค้นหา partition ที่อนุญาตให้ mount ดู ตามนี้

# showmount -e ff6600;">10.0.0.1

* กรุณาแก้ IP เป็น IP ของเครื่อง nfs server ของท่านครับ พอ list ได้ที่แล้วก็สั่ง mount ได้เลย

# mount ff0000;">10.0.0.1:339966;">/path/to/exports 0000ff;">/path/to/exports

กรณีการทำ load balancing แนะนำให้ mount ลงไปที่ path เดียวกันกับเครื่อง server ครับ
จะช่วยลดปัญหายุ่งยากลงได้เยอะ

และแล้วก็ผ่านพ้นกันไปเป็นที่เรียบร้อยสำหรับการประกาศผล admission 2551
ซึ่งผมก็ได้ไปร่วม ในฐานะเบื้องหลังของเว็บไซต์ http://admissions.bodinzone.com/ (อีกครั้ง)

สรุปคร่าวๆ ก็…
งานนี้ทีแรกนึกว่าจะหินมากกว่านี้ครับ
แต่เจอเข้าไป “แค่” 20 คำร้องต่อวินาที
(ย้ำว่าไอ้ 20 req/sec นี่ “แค่” จริงๆ สำหรับผม)

มาดูสถิติกันดีกว่าครับ
กราฟ CPU ไม่มีอะไรเปลี่ยนแปลง ขี้เกียจ cap ขอผ่านละกัน
เอาที่น่าสนใจหน่อย

กราฟ connection คงค้างในเซิฟเวอร์ครับ
ตั้งแต่เริ่มประกาศ คือก่อนเวลาประมาณ 18.00 น. นิดหน่อย มาจนถึงปัจจุบัน
ก็ยังมีการเรียกใช้งานอยู่เรื่อยๆ เห็นได้จากที่มีกราฟพุ่งปรี๊ดไปพอประมาณ

สรุปเทคนิค optimize ที่ใช้

1. DNS Round Robin
2. MySQL Indexes
3. MySQL Memory Engine

เอาไว้เดี๋ยวค่อยเขียนรายละเอียดของข้อ 2-3 ละกัน
จะได้ดูแล้วมีเนื้อหาเยอะๆ หน่อย blog นี้ (ฮา)

ว่าแต่ น้องๆ ทุกคนเป็นไงกันมั่งครับ
หวังว่าคงได้คณะที่อยากได้กันนะครับ ^^

กำหนดการปัจจุบัน วันที่ 4 พ.ค. 2551 เวลา 20.00 น. จะเริ่มประกาศพร้อมกันทุกเว็บทั่วประเทศ
ในการนี้ เพื่อนผมจากทาง bodinzone ก็เป็นผู้ร่วมประกาศผลด้วยเช่นกัน
(โดยมีผมเป็นเบื้องหลังเช่นเคย ฮาๆ)

งานนี้ถือว่าเป็นงานหินครับ เพราะ load กระจุกตัวมากๆ คือช่วงเวลาตั้งแต่ก่อนเริ่มประกาศ
จนถึงประกาศไปแล้ว 1 วันเต็มๆ จะเป็นวันที่คนเข้าเว็บประกาศผลกันอย่างมืดฟ้ามัวดิน
พาลจะทำให้เว็บเหล่านี้ล่มตามๆ กันซะด้วยสิ ซึ่งประกาศทุกปีก็ล่มกันทุกปี

ปีที่แล้วผมเลยเข้าร่วมทดสอบ load balancer แบบง่ายๆ
ใช้ DNS Round Robin ที่เคยเขียนไปแล้วนั่นแหละครับ
แล้วทำ สำเนาการประกาศผลมาไว้ด้วย โดยใช้ชื่อทีมของ bodinzone ปะหน้า

ผลปรากฎว่า… สบายๆ ครับ เนื่องด้วยเข้ามาช้าไปนิดนึง (หลังประกาศผลนิดหน่อย)

แต่ปีนี้สิ – -’ เตรียมการไว้เรียบร้อยแล้ว เหลือ up ฐานข้อมูลลง
เพราะฉะนั้น เราจะต้องรับงานล่วงหน้าด้วย T_T

รอดไม่รอด พรุ่งนี้มาวัดกันครับ

อ้อ ขอให้น้องๆ admission 51 โชคดี ได้คณะที่หวังที่อยากได้กันทุกคนนะครับ พี่จะคอยลุ้น อุอุ

จากเด็ก admission รุ่นแรก

หลักการมันง่ายๆ ครับ
แค่ชี้ Domain เดียวกันไปที่มากกว่า 1 IP ในกรณีของ IP (A) record นะ
แล้วที่เหลือก็ปล่อยเป็นหน้าที่ของเครื่องที่ค้นหา IP แล้วละครับว่าจะแจก IP ไหนให้
ซึ่งโดยมากก็จะเป็นแบบหมุนเวียน (round-robin) คือ
การสอบถามครั้งที่ 1 แจก IP ที่ 1 ให้
การสอบถามครั้งที่ 2 แจก IP ที่ 2 ให้
การสอบถามครั้งที่ 3 กลับมาแจก IP ที่ 1 อีกรอบ (กรณีมีแค่ 2 IP)

ตัวอย่างการตั้งค่าครับ ที่ใช้อยู่ปัจจุบัน

ข้อดีของระบบ DNS Round Robin นี้

1. ตั้งค่าง่ายมาก เพราะ DNS Server ส่วนมากในปัจจุบันรองรับอยู่แล้ว
2. (ในระบบแบบพื้นฐาน) ไม่ต้องมีการติดตั้งอุปกรณ์ใดๆ เพิ่มเติม แม้แต่ชิ้นเดียว
3. ช่วย network redundant ได้นิดหน่อย คือถ้าล่ม 1 IP, ที่เหลือก็ยังสามารถทำงานได้

แต่ในขณะเดียวกัน ข้อเสียใหญ่ที่สุด ที่เกิดขึ้นมาเพราะอยู่ในระบบ DNS เลยครับ
” มันติด cache ”
ทำให้เราไม่สามารถคาดคะเนผลลัพท์ได้เลยว่า เครื่องลูกข่ายจะสอบถามแล้วได้ IP อะไรตอบกลับไป
ทำให้ไม่สามารถควบคุมการเข้าถึง server ได้เลยว่า จะให้เน้นไปที่ server เครื่องไหน

ดังนั้น เครื่องที่จะทำ DNS-RR นี่ก็เลยควรจะเป็นเครื่องที่ spec ใกล้เคียงกันทั้งหมดครับ
ไม่เช่นนั้นจะเกิดเหตุการแบบนี้ครับ

server 1: CPU Xeon (p4) 3.0 GHz HyperThreading — load average: 2x.xx, 2x.xx, 1x.xx
server 2: CPU Xeon X3210 QuadCore 2.13GHz — load average: 3.xx, 2.xx, 2.xx

ผลปรากฎว่า คนไหนที่เข้าไปโผล่เครื่อง server 1 อืดจนแทบทำอะไรไม่ได้เลย T_T
ชีวิตมันน่าเศร้า