.

บริการ Public DNS จำพวก OpenDNS และ Google Public DNS ได้รับความสนใจอย่างมากเนื่องด้วยการโฆษณาว่าสามารถเพิ่มความเร็วในการเข้าชมเว็บไซต์ได้มากขึ้นเพียงแค่เปลี่ยนการตั้งค่า DNS resolver บนเครื่องคอมพิวเตอร์ของคุณเท่านั้น สาเหตุหนึ่งก็เนื่องมาจาก ISP หลายๆ รายไม่ได้ลงทุนในการทำโครงสร้าง DNS ให้ดี ซึ่งทำให้ความเร็วในการตอบสนองช้าโดยเฉพาะช่วงเวลาเร่งด่วน จึงได้มีบริการ Public DNS ที่สร้างเพื่อรองรับปริมาณกาการใช้งาน DNS มหาศาลเหล่านี้… แต่มันดีขึ้นจริงๆ หรือ?

ก่อนอื่น เราต้องเข้าใจก่อนว่า ISP ที่เราใช้บริการอยู่ จะมี DNS resolver ที่ติดตั้งอยู่ภายในเครือข่ายเดียวกับที่เราต่อเน็ตเข้าไป ส่วนการใช้บริการจากภายนอกอย่างเช่น OpenDNS หรือ Google DNS service นั้นจะเป็นการเชื่อมต่อออกภายนอกเครือข่าย ซึ่งทำให้การติดต่อ DNS เหล่านั้นต้องเดินทางไกลขึ้นเพื่อที่จะไปให้ถึง Server (โดยเฉพาะการใช้งานจากประเทศไทย ที่ไม่ว่า Google DNS หรือ OpenDNS ล้วนแล้วแต่อยู่ต่างประเทศทั้งสิ้น : เพิ่มเติมโดยผู้แปล) และอย่าลืมว่า การเดินทางที่ไกลขึ้น เท่ากับว่าต้องใช้เวลามากขึ้นกว่าการรับส่งข้อมูลจะสมบูรณ์

* เพิ่มเติม: การใช้งาน Google DNS ในประเทศไทย จะติดต่อไปยัง server ของ Google ที่สิงคโปร์ ส่วน OpenDNS นั้นต้องติดต่อไปไกลถึงอเมริกาเลยทีเดียว

แล้ว DNS มีผลต่อการเข้าชมเว็บไซต์มากขนาดไหน? คำตอบคือ “น้อยมาก” เพราะการเข้าชมเว็บไซต์แต่ละครั้ง ใน “ครั้งแรก” ก่อนการเชื่อมต่อ เครื่องคอมพิวเตอร์จะสอบถามข้อมูล IP ของเว็บไซต์ไปยัง DNS resolver ตามที่ได้ระบุไว้ จากนั้นจึง “เก็บ” ข้อมูลดังกล่าวไว้ภายในหน่วยความจำตลอดการเข้าใช้งาน หรือจนกว่าข้อมูลจะหมดอายุไปตามที่ได้ระบุใน DNS ของแต่ละ domain เอง (ในค่า TTL) ดังนั้นถึงแม้ว่าการที่เราใช้ DNS resolver ที่เร็วกว่า ก็ไม่ได้หมายความว่าเราจะสามารถโหลดข้อมูลเว็บไซต์ได้เร็วกว่าแต่อย่างใด ในทางปฏิบัติจริงๆ แล้ว มันสามารถช่วยได้เพียงเล็กน้อย … ซึ่งวัดกันในหน่วย มิลลิวินาที (1/1000 วินาที) ด้วยซ้ำไป

แล้วทีนี้? ปัจจุบันเนื่องจากปริมาณข้อมูลที่ถูกสร้างจากผู้ใช้ (user-generated content) มีมากขึ้นเรื่อยๆ ประกอบกับการขยายตัวของบริการซอฟต์แวร์ (software-as-a-service) ทำให้หลายๆ บริษัทมองมาที่ระบบ CDN (Content Delivery Networks) ที่ช่วยกระจายข้อมูลให้ผู้ใช้งาน โดยหลักการง่ายๆ ก็คือ ระบบ CDN จะกระจายข้อมูลเหมือนๆ กันลงไปที่แต่ละ node ทั่วโลก แล้วเมื่อผู้ใช้ต้องการเรียกใช้งาน ระบบ CDN ก็จะส่งข้อมูลไปให้จาก node ที่อยู่ “ใกล้ผู้ใช้” มากที่สุด ทำให้ผู้ใช้สามารถเรียกข้อมูลได้เร็วขึ้นมาก รวมถึงการลดปริมาณการใช้งาน bandwidth ของเจ้าของเว็บไซต์อีกด้วย

แล้ว DNS มาเกี่ยวอะไรด้วย? วิธีตรวจสอบที่อยู่ว่า ผู้ใช้ร้องขอการใช้งานจากส่วนไหนของโลกของ CDN ส่วนใหญ่ จะใช้วิธีตรวจสอบจากที่มาของการสอบถามข้อมูล IP ผ่าน DNS resolver … ซึ่งการสอบถาม IP นี้ browser จะสอบถามไปยัง DNS resolver ตามที่ตั้งค่าไว้ จากนั้น DNS resolver ดังกล่าวจึงไปร้องขอข้อมูล IP จาก Nameserver ที่รับการใช้งานของ domain นั้นๆ อีกที (เรียกว่า Authoritive NS) แล้ว Nameserver ก็จะตรวจสอบที่มาของการร้องขอข้อมูลนั้น แล้วส่ง IP ที่อยู่พื้นที่ใกล้เคียงที่สุดไปให้

ปัญหามันเกิดขึ้นเมื่อ… คุณไม่ได้ใช้ DNS resolver ของ ISP ที่อยู่ใกล้เคียงคุณมากที่สุด นั่นจะทำให้คุณได้รับ IP ของ CDN ที่อยู่ใกล้เคียง DNS resolver แทน อย่างเช่นหากคุณใช้บริการอย่าง OpenDNS ไปร้องขอ IP ของเว็บไซต์ … คุณจะได้รับ IP ของประเทศอเมริกากลับมา ทำให้การใช้งานเป็นไปอย่างล่าช้ามากกว่าเดิมมาก ซึ่งเป็นผลให้คุณเข้าถึงข้อมูลที่อยู่บนบริการ CDN ได้ช้าลงมากๆ ด้วย และอย่าลืมว่า DNS request ใช้ปริมาณข้อมูลเพียงไม่กี่ byte เท่านั้น แต่การรับส่งข้อมูลของบริการ CDN นั้นต่างกันอย่างมหาศาล เนื่องจากข้อมูลส่วนใหญ่ของ CDN จะเป็นรูปภาพและวีดีโอ ซึ่งขนาดใหญ่กว่ากันมากขึ้นอย่างสังเกตได้ชัดเจนมากๆ เลยทีเดียว

ถึงแม้ว่า OpenDNS จะมีบริการเสริมอย่างเช่นการกรองข้อมูล และป้องกันฟิชชิ่ง (phishing) ด้วยก็ตาม แต่ถ้าเป้าหมายหลักของคุณคือการทำให้การเข้าเว็บเร็วขึ้น ดังนั้นควรเลี่ยงบริการ public DNS เหล่านี้ โดยเฉพาะหากเว็บไซต์ที่คุณเข้าใช้บริการบ่อยๆ มีการใช้ CDN ด้วยอย่างเช่น Facebook และ Youtube

.

.

ด้านล่างนี่ผลการทดสอบครับ
ต้นทางทดสอบจาก CAT-IDC กสท.บางรักครับ

Google Public DNS
Answer = 58.27.22.0/24 => Malaysia
Time = 42ms

;; QUESTION SECTION:
;static.ak.fbcdn.net. IN A

;; ANSWER SECTION:
static.ak.fbcdn.net. 5226 IN CNAME static.ak.facebook.com.edgesuite.net.
static.ak.facebook.com.edgesuite.net. 19130 IN CNAME a749.g.akamai.net.
a749.g.akamai.net. 14 IN A 58.27.22.26
a749.g.akamai.net. 14 IN A 58.27.22.91
a749.g.akamai.net. 14 IN A 58.27.22.65
a749.g.akamai.net. 14 IN A 58.27.22.9
a749.g.akamai.net. 14 IN A 58.27.22.32
a749.g.akamai.net. 14 IN A 58.27.22.42

;; Query time: 42 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Wed Jun 16 19:59:15 2010
;; MSG SIZE rcvd: 208

OpenDNS
Answer = 208.50.77.0/24 => USA
Time = 236ms

;; QUESTION SECTION:
;static.ak.fbcdn.net. IN A

;; ANSWER SECTION:
static.ak.fbcdn.net. 6302 IN CNAME static.ak.facebook.com.edgesuite.net.
static.ak.facebook.com.edgesuite.net. 20706 IN CNAME a749.g.akamai.net.
a749.g.akamai.net. 10 IN A 208.50.77.113
a749.g.akamai.net. 10 IN A 208.50.77.72
a749.g.akamai.net. 10 IN A 208.50.77.81
a749.g.akamai.net. 10 IN A 208.50.77.96

;; Query time: 236 msec
;; SERVER: 208.67.222.222#53(208.67.222.222)
;; WHEN: Wed Jun 16 19:59:33 2010
;; MSG SIZE rcvd: 176

THZHosting Public DNS (node ที่ csloxinfo cbw idc)
Answer = 203.146.247.0/24 => Thailand (CSLoxinfo)
Time = 4ms

;; QUESTION SECTION:
;static.ak.fbcdn.net. IN A

;; ANSWER SECTION:
static.ak.fbcdn.net. 7121 IN CNAME static.ak.facebook.com.edgesuite.net.
static.ak.facebook.com.edgesuite.net. 21522 IN CNAME a749.g.akamai.net.
a749.g.akamai.net. 20 IN A 203.146.247.38
a749.g.akamai.net. 20 IN A 203.146.247.37

;; Query time: 4 msec
;; SERVER: 203.146.215.116#53(203.146.215.116)
;; WHEN: Wed Jun 16 19:59:58 2010
;; MSG SIZE rcvd: 306

CAT ISP DNS Server
Answer = 61.19.12.0/24 => Thailand (CAT IDC)
Time = 0ms

;; QUESTION SECTION:
;static.ak.fbcdn.net. IN A

;; ANSWER SECTION:
static.ak.fbcdn.net. 3800 IN CNAME static.ak.facebook.com.edgesuite.net.
static.ak.facebook.com.edgesuite.net. 18200 IN CNAME a749.g.akamai.net.
a749.g.akamai.net. 20 IN A 61.19.12.41
a749.g.akamai.net. 20 IN A 61.19.12.72

;; Query time: 0 msec
;; SERVER: 61.19.245.245#53(61.19.245.245)
;; WHEN: Wed Jun 16 20:27:49 2010
;; MSG SIZE rcvd: 150

shell script (จำที่มาไม่ได้ ขออภัยด้วยครับ)

#!/bin/bash
cd /tmp
/bin/rm -f GeoIPCountryCSV.zip
wget -T 5 -t 1 http://geolite.maxmind.com/download/geoip/database/GeoIPCountryCSV.zip
unzip GeoIPCountryCSV.zip || exit 1
 
echo -n "Creating CNM (Country,Net/Mask) CSV file..."
awk -F \" 'function s(c,b,e,l,m,n) {l = log(e-b+1)/log(2); m = 2^32-2^int(l); n = and(m,e); if (n == and(m,b)) {printf "%s,%u.%u.%u.%u/%u\n",c,b/2^24%256,b/2^16%256,b/2^8%256,b%256,32-l} else {s(c,b,n-1); s(c,n,e)}} s($10,$6,$8)' GeoIPCountryWhois.csv > cnm.csv
rm -f GeoIPCountryWhois.csv
echo -ne "DONE\nGenerating BIND GeoIP.acl file..."
 
(for c in $(awk -F , '{print $1}' cnm.csv | sort -u)
do
  echo "acl \"$c\" {"
  grep "^$c," cnm.csv | awk -F , '{print "\t"$2";"}'
  echo -e "};\n"
done) > /etc/named.GeoIP.acl
 
rm -f cnm.csv
echo "DONE"
 
/etc/init.d/named reload
 
exit 0

แล้วไปแก้ named.conf

include "/etc/named.GeoIP.acl";
view "thailand" {
    match-clients { TH; };
        match-clients { TH; };
        zone "upic.me" {
                type master;
                file "master/th.db.upic.me";
        };
}
view "inter" {
        match-clients { any; };
        zone "upic.me" {
                type master;
                file "master/all.db.upic.me";
        };
};

อยากได้ประเทศไหนก็ลองดู code ในไฟล์ /etc/named.GeoIP.acl ละกันครับ
ส่วน… script ด้านบน
เซฟแล้วเอาใส่ใน cron ด้วยเลยจะดีมาก รันสัปดาห์ละครั้ง

ก่อนอื่นก็ต้องมาไล่กันที่ระบบ Root DNS ก่อน

Tracing to icez.net[a] via I.ROOT-SERVERS.NET, maximum of 1 retries
I.ROOT-SERVERS.NET (192.36.148.17)
|\___ I.GTLD-SERVERS.net [net] (192.43.172.30)
|     |\___ ns6.thzhost.com [icez.net] (203.146.170.140) Got authoritative answer
|      \___ ns2.thzhost.com [icez.net] (203.146.129.182) Got authoritative answer
…..
|\___ K.GTLD-SERVERS.net [net] (192.52.178.30)
|     |\___ ns6.thzhost.com [icez.net] (203.146.170.140) (cached)
|      \___ ns2.thzhost.com [icez.net] (203.146.129.182) (cached)
\___ J.GTLD-SERVERS.net [net] (192.48.79.30)
|\___ ns6.thzhost.com [icez.net] (203.146.170.140) (cached)
\___ ns2.thzhost.com [icez.net] (203.146.129.182) (cached)

ns2.thzhost.com (203.146.129.182)       icez.net -> 203.146.129.182
ns6.thzhost.com (203.146.170.140)       icez.net -> 203.146.129.182

นี่แหละครับ วิธี lookup ของระบบ DNS
ไอ้เจ้า I.ROOT-SERVERS.NET นี่เป็น server ของ ICANN ครับ
ทำหน้าที่รองรับ DNS request ของระดับ TLD
คือเป็น authoritive zone ของ TLD ทุกอัน
หากเกิด TLD ใหม่ขึ้นมาก็มาถามที่นี่ได้ครับว่ามันชี้ไปที่ไหนต่อ
จริงๆ ROOT SERVERS นี่มีเยอะครับ แต่เผอิญว่า I.ROOT-SERVERS.NET มันอยู่ในไทย (ที่ กสท) ก็เลยใช้ตัวนี้ซะเลย

ลำดับต่อมา พอได้ DNS ของ TLD มาแล้ว ก็ไปถามต่อว่า domain เราอยู่ DNS ไหน
(จริงๆ มันถามแค่ที่เดียวนะครับ นี่พอดีใช้ tool ช่วยนิดหน่อย มันเลยขึ้นมาหมดเลย)
อย่างกรณี .com .net พวกนี้จะมี GTLD-SERVERS.NET ของ verisign เป็นผู้ดูแล
ของไทยก็เป็น THNIC ดูแลอยู่ อะไรประมาณนี้แหละครับ

ทีนี้ เวลาได้ “ชื่อ” ของ nameserver มาแล้วเนี่ย เซิฟเวอร์มันจะบอก “IP” มาให้ด้วยเลย
ตามที่เราได้ลงทะเบียน nameserver ไว้นั่นแหละครับ
นั่นหมายความว่า ไม่ใช่ว่าอยู่ดีๆ เราจะตั้ง nameserver ทั่วไปได้เลย
ยังไงก็ต้องลงทะเบียนกับผู้ให้บริการจดโดเมนก่อน
ถ้าเอา “ชื่อ” ของ nameserver ไป lookup ดูมันก็จะได้อย่างนี้ครับ

Tracing to ns2.thzhost.com[a] via I.ROOT-SERVERS.NET, maximum of 1 retries
I.ROOT-SERVERS.NET (192.36.148.17)
|\___ F.GTLD-SERVERS.NET [com] (192.35.51.30) Got answer
|     |\___ ns6.thzhost.com [thzhost.com] (203.146.170.140) Got authoritative answer
|      \___ ns2.thzhost.com [thzhost.com] (203.146.129.182) Got authoritative answer
|\___ E.GTLD-SERVERS.NET [com] (192.12.94.30) Got answer
|     |\___ ns6.thzhost.com [thzhost.com] (203.146.170.140) (cached)
|      \___ ns2.thzhost.com [thzhost.com] (203.146.129.182) (cached)
……
|\___ I.GTLD-SERVERS.NET [com] (192.43.172.30) Got answer
|     |\___ ns6.thzhost.com [thzhost.com] (203.146.170.140) (cached)
|      \___ ns2.thzhost.com [thzhost.com] (203.146.129.182) (cached)
|\___ H.GTLD-SERVERS.NET [com] (192.54.112.30) Got answer
|     |\___ ns6.thzhost.com [thzhost.com] (203.146.170.140) (cached)
|      \___ ns2.thzhost.com [thzhost.com] (203.146.129.182) (cached)
\___ G.GTLD-SERVERS.NET [com] (192.42.93.30) *

H.GTLD-SERVERS.NET (192.54.112.30)      ns2.thzhost.com -> 203.146.129.182
I.GTLD-SERVERS.NET (192.43.172.30)      ns2.thzhost.com -> 203.146.129.182
K.GTLD-SERVERS.NET (192.52.178.30)      ns2.thzhost.com -> 203.146.129.182
M.GTLD-SERVERS.NET (192.55.83.30)       ns2.thzhost.com -> 203.146.129.182
A.GTLD-SERVERS.NET (192.5.6.30)         ns2.thzhost.com -> 203.146.129.182
D.GTLD-SERVERS.NET (192.31.80.30)       ns2.thzhost.com -> 203.146.129.182
E.GTLD-SERVERS.NET (192.12.94.30)       ns2.thzhost.com -> 203.146.129.182
ns2.thzhost.com (203.146.129.182)       ns2.thzhost.com -> 203.146.129.182
ns6.thzhost.com (203.146.170.140)       ns2.thzhost.com -> 203.146.129.182
F.GTLD-SERVERS.NET (192.35.51.30)       ns2.thzhost.com -> 203.146.129.182

เห็นมั้ยครับว่า พอลงทะเบียน nameserver แล้ว
ไอ้ GTLD SERVERS แทนที่จะตอบว่า domain นี้มี dns อะไร
มันก็เลยตอบพ่วง IP มาให้ด้วยเลย

ตรงจุดนี้คือจุดที่ผิดพลาดกันอันดับแรกๆ เลยครับ
ก็คือ สมมติ domain icez.net ชี้ไปที่ ns2.thzhost.com กับ ns6.thzhost.com
แต่ใน domain thzhost.com ไม่มี record ของ ns2.thzhost.com กับ ns6.thzhost.com
ก็อาจทำให้ไม่สามารถ lookup ได้ เพราะ dns บางตัวจะไม่เอา ip มาจาก gtld-servers คือจะไป lookup หาเองตรงๆ
แล้วมันหา ip ของ nameserver ไม่เจอ หรือ IP ไม่ตรงกันกับที่ลงทะเบียนไว้ ก็เน่าครับ

———————————————

มากันที่จุดที่สอง: ว่าด้วย “NS record”
เหมือนจะง่ายครับ
แค่ชี้ใน domain ให้ตรงกับที่ lookup ขึ้นมาได้
อย่างของ icez.net ก็คือ ns2.thzhost.com กับ ns6.thzhost.com
ก็เข้าไปตั้งค่าใน DNS Server ตามนี้เลยครับ

icez.net. IN NS ns2.thzhost.com.
icez.net. IN NS ns6.thzhost.com.

———————————————

จุดที่สาม: IP ของ nameserver
นอกจากที่เราไปลงทะเบียน nameserver ไว้กับที่จดโดเมนแล้ว
เราก็ต้องมาเซตที่เครื่อง dns server เราด้วยครับ
ns2.thzhost.com กับ ns6.thzhost.com คือ subdomain ของ domain thzhost.com
ก็เข้าไปที่ DNS Server ของ thzhost.com
ไปเพิ่ม record ตามนี้ครับ

ns2 IN A 203.146.129.182
ns6 IN A 203.146.170.140

———————————————

จบ เห้อ ยาวดีจัง ไม่ได้เขียนอะไรยาวๆ แบบนี้มาพักนึงและ
ไม่รู้เรื่องอย่าว่ากันนะครับ (ฮา) เขียนตอนเช้าก็เงี้ย

RewriteEngine On
RewriteBase /

RewriteCond %{REQUEST_URI} !\.php$
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule . – [L]

000000;">RewriteCond %{HTTP_HOST} !www.icez.net
RewriteCond %{HTTP_HOST} !^icez.net
RewriteCond %{HTTP_HOST}<>%{REQUEST_URI} ^([^.]+)\.icez\.net(:80)?<>/([^/]*) [NC]
RewriteCond %1<>%3 !^(.*)<>\1$ [NC]
RewriteRule ^(.*)$ /%1/$1 [L,QSA]

เจอปัญหาอย่างนึงว่า ถ้าสมมติเข้าเว็บ อย่าง http://something.icez.net/
แล้วไม่มี folder ชื่อนี้อยู่ในระบบเนี่ย
มันจะเด้งหน้า Internal Server Error ขึ้นมาเลย
แก้ได้แล้วค้าบบบบ ไม่เจอแล้ว เย้ๆๆๆๆๆๆๆๆๆ
(ถ้าไม่เจอ subdomain จะขึ้นหน้า 404 ธรรมดาแทน)

อ้อ ถ้าใครจะเอาไปทำ อย่าลืมเพิ่ม config apache ลงใน virtual host ด้วยนะครับ

ServerAlias *.icez.net

ตามนี้เลยฮะ (แก้ตัวสีน้ำเงินด้วยน่อ)
แล้วก็อย่าลืมไป add DNS record ด้วยนะจ๊ะ

*.icez.net. IN A 203.146.129.182

.

.

แก้ไขเพิ่มเติมจ้าาาา ด้านบนเลย ^^”

และแล้วก็ผ่านพ้นกันไปเป็นที่เรียบร้อยสำหรับการประกาศผล 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
ชีวิตมันน่าเศร้า