Ruby + Gmail ทำให้งานเราสบายขึ้น

ด้วยความขี้เกียจที่จะต้องมานั่งทำรายงาน ทุกเช้า เช่น ตรวจสถานะ CPU, แรม, เนื้อที่ Harddisk สถานะ บลา บลา กว่าจะเสร็จก็ปาไปร่วมชั่วโมง ก็เลยหาวิธี ให้มัน สรุปรายงานในเครื่องแล้วส่งเข้าอีเมล์ไปเลย

เพื่อให้คง concept ไว้ก็เลยเลือกใช้งาน Ruby ส่งผ่าน gmail Account ไปเลย (ลองทดสอบใช้กับ Google Apps ก็ได้นะ)

ขั้นตอนการเตรียมพร้อม ติดตั้ง Gems ให้เรียบร้อยก่อน

# gem install tmail
# gem install mime
# gem install ruby-gmail

จากนั้น ทดลองเขียนโปรแกรมง่ายๆ เพื่อส่งข้อความ

#!/usr/local/bin/ruby

require 'rubygems'
#require 'mime-types'
require 'gmail'

gmail = Gmail.new('xxxx@gmail.com', 'your_password')
# send commands

# or generate message and send it later
email = gmail.generate_message do
  from "xxxxx@gmail.com"
  to "xxxxxx_receive@gmail.com"
  subject "Not feeling well"
  body "I won't be coming in today. So you will eating lunch alone."
end

email.deliver!

gmail.logout
# logged out

จะได้ผลลัพธ์ประมาณนี้

[nutjang@dhcppc7 ~/ruby/gmail]$ ./test.rb
-> "220 mx.google.com ESMTP d2sm930264qcs.21\r\n"
<- "EHLO xxxxxxxxxxxxxxxx\r\n"
-> "250-mx.google.com at your service, [124.121.44.166]\r\n"
-> "250-SIZE 35882577\r\n"
-> "250-8BITMIME\r\n"
-> "250-STARTTLS\r\n"
-> "250 ENHANCEDSTATUSCODES\r\n"
<- "STARTTLS\r\n"
-> "220 2.0.0 Ready to start TLS\r\n"

บลา บลา บลา ....ย้าว ยาว

wrote 353 bytes
-> "250 2.0.0 OK 1308800894 d2sm930264qcs.21\r\n"
<- "QUIT\r\n"
-> "221 2.0.0 closing connection d2sm930264qcs.21\r\n"
[nutjang@dhcppc7 ~/ruby/gmail]$

จากนั้นก็ลองไปตรวจสอบ Inbox ปลายทางดู ก็จะเห็นอีเมล์ส่งมาจ้า

สรุปว่า Happy ทั้งคนทำงาน ไม่ต้องนั่งทำรายงานแล้ว , เจ้านาย ก็มีรายงานทุกเช้า เย้!

Nginx Web Cluster (ตอนที่ 2)

ต่อจากตอนแรก ยังคงมีปัญหาค้างอยู่คือ เครื่องที่ทำหน้าที่ Load Balance นั้น มีแค่เครื่องเดียว ซึ่งเป็น Single point of failure อยู่
จำเป็นที่จะต้องทำให้ Load Balance นี้ มีตัวตายตัวแทน

วิธีแก้ปัญหา -> ใช้ Common Address Redundancy Protocol (CARP)

1. ที่เครื่อง Load Balance ทั้ง 2 เครื่อง ต้อง compile Kernel FreeBSD ใหม่

โดยเพิ่ม device carp เข้าไป

# cd /usr/src/sys/amd64/conf
# cp GENERIC GENERIC.carp

เพิ่ม device carp เข้าไป แล้วเซฟ

# config GENERIC.carp
# cd ../compile/GENERIC.carp
# make depend
# make
# make install

restart เครื่อง 1 รอบ

ทำอย่างนี้ที่ เครื่อง Loadbalance1 และ Loadbalance2

cloned_interfaces="carpXX"
ifconfig_carpXX="vhid advskew pass "

ตัวอย่างเครื่องที่ 1
/etc/rc.conf

ifconfig_bge1="inet 192.168.10.2 netmask 255.255.255.0"

cloned_interfaces="carp1"
ifconfig_carp1="vhid 10 advskew 50 pass password 192.168.10.1"

ตัวอย่างเครื่องที่ 2
/etc/rc.conf

ifconfig_bge1="inet 192.168.10.3 netmask 255.255.255.0"

cloned_interfaces="carp1"
ifconfig_carp1="vhid 10 advskew 80 pass password 192.168.10.1"


ขั้นตอนสุดท้าย แก้ไขไฟล์ /etc/sysctl.conf โดยเพิ่มบรรทัดต่อไปนี้เข้าไป

net.inet.carp.preempt=1


Restart แล้ว ทดลอง ดู ifconfig ที่เครื่องแรกดู จะเป็น interface carp up และมี IP เป็น 192.168.10.1


อ้างอิง

cloned_interfaces="carpXX"

Add an ifconfig variable for each CARP interface that was created.

ifconfig_carpXX="vhid advskew pass "

The is an identifier that groups the CARP interface with it's counterpart interface on the other hosts. The common IP address is shared with all interfaces that have the same . The may be anything but must match on all the hosts.
The should be different on each host. The value on the master host should be less than the backup hosts.
is a string used to validate the CARP exchanges between the hosts. This can be any string you want but must be the same on all hosts that share a common .
The is the virtual IP address that the CARP interface will have. This IP address must be in the network block assigned to one of the physical interfaces. CARP uses this IP address to figure out what physical interface to assign the CARP interface too.

Nginx Web Cluster (ตอนที่ 1)

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

1. ระบบจะต้อง รองรับการทำงานที่หนักขึ้น ซึ่ง เครื่องเดียวอาจจะรับ Load ทั้งหมดไม่ได้ ต้องกระจายระบบ ออกไป
2. สำหรับระบบใหม่นี้ จะต้องไม่มี Single point of failure.

เพื่อคง Concept จะยังคงใช้ FreeBSD อยู่เหมือนเดิม

ทางเลือกของเราคือ ใช้ Nginx ทำหน้าที่เป็น Load Balance ข้างหน้า 2 ตัว ส่วน Backend Server Cluster จะเป็น Apache หรือ Nginx ก็ได้
ในตอนนี้จะอธิบายในส่วนของการทำ Backend Server Clusterก่อน

- ในส่วน nginx.conf ให้เพิ่ม config ในลักษณะนี้เข้าไป จาก config จะเห็นว่า เรามี backend อยู่ 4 ตัว และ กำหนดให้ตัวที่ 1 ทำงานเป็น 3 เท่าของตัวอื่นๆ (weight 3)

- ในส่วนของการ config server ก็ ใช้ proxy_pass ไปยัง cluster ของเรา

http {
  upstream backend_cluster {
    server 192.168.1.10:80 weight=3;
    server 192.168.1.11:80;
    server 192.168.1.12:80;    
    server 192.168.1.13:80;
  }
 
  server {
    listen 80;
    server_name www.domain.com;
    location / {
      proxy_pass http://backend_cluster;
    }
  }
}

- ในส่วนของ Backend Cluster ก็คือ เครื่องที่เป็น Web Server ปกติ นั่นเอง
- ลอง Restart nginx แล้ว ทดสอบการทำงานดูได้เลย
- การสลับการทำงาน ของ แต่ละ server จะเป็น แบบ Round Robin อยู่

อยากรู้ว่า ตอนนี้ Servier FreeBSD Interface ใช้ Bandwidth เท่าไร

ให้ใช้คำสั่งนี้

# systat -ifstat 1

หรือ

# netstat -I interface_name seconds
# netstat -I re0 1

ตัวอย่างผลลัพธ์

systat -ifstat 1

               /0   /1   /2   /3   /4   /5   /6   /7   /8   /9   /10
Load Average   |

  Interface           Traffic               Peak                Total
        lo0  in      2.083 KB/s          2.085 KB/s            2.405 GB
             out     2.083 KB/s          2.085 KB/s            2.405 GB
        igb0  in    157.649 KB/s        184.839 KB/s          532.378 GB
             out   843.810 KB/s        865.344 KB/s            2.802 TB

[nutjang@3bb-www ~]$ netstat -I igb0 1
            input         (igb0)           output
   packets  errs idrops      bytes    packets  errs      bytes colls
      1368     0     0     151671       1058     0     922696     0
      1436     0     0     176304       1143     0    1098265     0
      1293     0     0     152111       1069     0     720428     0
      1544     0     0     190381       1244     0     954721     0
      1556     0     0     186997       1228     0     912025     0
      1598     0     0     187766       1196     0     883343     0
      1447     0     0     169208       1135     0     840569     0
      1592     0     0     190451       1196     0     864030     0
      1727     0     0     193916       1349     0    1044825     0
      1498     0     0     195785       1171     0     860164     0

ใช้ MySQL cluster เมื่อ ต้องการระบบ ขยาย

โอ้ว ตอนนี้ งานที่ทำงาน ดันลูกค้าเข้าเยอะมาก ทำให้คนดูแลเซิฟเวอร์อย่างเราต้อง นอนหลับไม่สนิทเลย เวลา SMS เข้า.

สาเหตุก็มาจาก ความตกใจเกินเหตุ อะไรๆ ก็ alert เข้า SMS หมด.

ดังนั้น เมื่อระบบขยาย ใครๆก็ไม่อยากให้ Server down ดังนั้น ก็ทำให้มัน เพิ่มความเสถียรซะหน่อยเป็นไง

MySQL ก็มีฟังก์ชั่น สำหรับการทำ cluster อยู่แล้วนะครับ เพียงแต่ว่า จะเปิดออกมาใช้งานหรือเปล่าแค่นั้นเอง

ตอนนี้กำลังนั่งออกแบบระบบ cluster ให้กับที่ทำงานอยู่ ไม่รู้ว่าจะใช้งบเท่าไรดี แต่ที่แน่ๆ งานนี้ไม่ต่ำกว่า 7 หลัก แน่ๆอิอิ.

ปล. ออกไปรับจ้าง ทำระบบ database cluster ขนาดย่อม ดีไหมนี่

ถ้าเกิดตาราง ใน mysql พัง

ชื่อตาราง marked as crashed and should be repaired

นี่เป็นวิธีแก้ไขอย่างง่าย ด้วยคำสั่งดังต่อไปนี้

#myisamchk -r -q tbl_name

อย่างกรณีของจะได้ผลลัพธืดังต่อไปนี้

- check record delete-chain
- recovering (with sort) MyISAM-table 'hb_log'
Data records: 808714
- Fixing index 1

จากนั้นลองมาตรวจสอบดู พบว่า ถ้าพบว่าข้อมูลในตารางมาครบ ก็เป็นอันจบเรียบร้อย