****** วิธีนี้ไม่รับประกันว่าสามารถลงคู่กับเครื่องที่มี DirectAdmin ได้ ******

1) EPEL

centos 5 :

rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-4.noarch.rpm

centos 6 :

rpm -Uvh http://download.fedora.redhat.com/pub/epel/6/x86_64/epel-release-6-5.noarch.rpm

2) Atomic

wget -qO - http://www.atomicorp.com/installers/atomic | sh

พร้อมแล้วก็ติดตั้งกันได้เลยครับ
CentOS 64-bit:

yum -y install zabbix-server-mysql.x86_64 zabbix-web-mysql.x86_64

CentOS 32-bit:

yum -y install zabbix-server-mysql zabbix-web-mysql

เปิดไฟล์ /etc/zabbix/zabbix_server.conf ขึ้นมา
แก้ไข option เกี่ยวกับการเชื่อมต่อ database ประมาณนี้

DBHost=localhost
DBName=zabbix
DBUser=zabbix
DBPassword=zbx@localhost

แล้วก็ import database

cat /usr/share/doc/zabbix-server-mysql-*/create/schema/mysql.sql /usr/share/doc/zabbix-server-mysql-*/create/data/*.sql | mysql -u zabbix -p zabbix

แล้วเข้าเว็บได้เลยฮะ http://IP/zabbix/ มันจะเด้งเข้าหน้าติดตั้งให้เลย
ก็ทำไปตามขั้นตอน ปรับตั้งค่า php.ini แล้วก็ระบุ user/pass เข้าฐานข้อมูลครับ
เสร็จแล้วให้ login ด้วย user admin / pass zabbix

* สำหรับ directadmin สั่ง ln -s /usr/share/zabbix /var/www/html/ เพิ่มอีกคำสั่งครับ

ตอนต่อไป (ที่ไม่รู้ว่าจะมาเมื่อไหร่) พบกับการตั้งค่า zabbix เบื้องต้นครับ

โดยการทดสอบก็คือ เว็บไซต์ทุกเว็บที่เข้าร่วม จะทำการเปิดให้เข้าถึง
www.DOMAIN.com ของตัวเองผ่าน IPv6 ได้ด้วย (จากเดิมที่เปิดเฉพาะ IPv4)
รอบนี้ @pawoot สั่งตรงมาเอง tarad.com ก็เลยเข้าร่วมแบบวุ่นวายกันพอสมควร (ฮา)

จริงๆ แล้วเคยทดสอบมาได้พักนึงแล้วครับ ipv6 เนี่ย
upic.me ก็มี http://v6.upic.me/ (แต่มันเข้าได้มั่งไม่ได้มั่ง อย่าไปพยายามเลย T_T)

ทีนี้ จากที่ทำมาก็เจอปัญหาพอสมควร บวกกับเรื่องที่น่าห่วงอีกหลายๆ อย่างที่คนดูแล network ไม่ควรมองข้ามเลย

• firewall ipv6 ไม่ได้ออกแบบมาให้มี private address (ถึงมันจะมี link-local address มาก็เหอะ) หมายความว่า เครื่องคอมพิวเตอร์ทุกเครื่องที่มี ipv6 สามารถคุยกันได้โดยตรงทั้งสองทาง ไม่ต้อง forward port ให้วุ่นวาย … หมายความว่า มันเปิดโอกาสให้ hacker เล่นงานได้สะดวกโยธินขึ้นเยอะ เพราะงั้น สิ่งสำคัญที่สุดของ ipv6 คือ firewall ครับ เปิดรอไว้ได้เลย ip6tables บน linux
• software compatibility ฝั่ง server ไม่ค่อยน่าห่วงเท่าไหร่ แต่ระดับ application ที่เอามาลง บาง app จะมีการเก็บหมายเลข IP ไว้ในฐานข้อมูล ซึ่งประกาศความกว้างรองรับไว้แค่ ipv4 (15 ตัวอักษร หรือเป็น integer 32bit) ซึ่งถ้าเกิดเข้าเว็บผ่าน ipv6 ก็จะทำให้การเก็บ log ไม่สมบูรณ์ ip ถูกตัดทอนหายไปไม่ครบหลักได้
• dual stack or nativeจริงๆ อันนี้ตัดสินใจไม่ยากครับ ช่วงนี้ก็ dual stack แหลก ไม่งั้นเกิดไปอยู่ในโลกของ ipv4 เดี๋ยวจะซวย connect ไปหา ipv6 ไม่ได้แล้วจะแย่ (ถึงมันมีตัวช่วยพวก tunnel ให้ก็เหอะ)
• transparent proxy ipv6 ไม่มี NAT แล้วนะครับ !!!! บน linux ipv6 ทำ nat ไม่ได้เลยไม่ว่ารูปแบบใดๆ ก็ตาม (ip6tables -t nat ขึ้น invalid table เลย) ทำให้หมดสิทธิ์ใช้งาน transparent proxy ที่ต้องการใช้ feature redirect port ไปเลยทีเดียว… แต่มีทางแก้ครับ squid version ใหม่รองรับการทำ transparent proxy แบบ TPROXY แล้ว (แต่ยังไม่สมบูรณ์) ยังไม่ได้ทดสอบ
• ip address assignment policy ipv6 มัน assign ทีนึงให้มาเป็น block ใหญ่ๆ แบบ /64 ขึ้นไป… การ assign ip address ก็เลยค่อนข้างวุ่นวาย โดยเฉพาะถ้าจะทำ static ip ให้ server … ตอนนี้ยังไม่มีอะไรในหัวเลยครับ แต่หลักๆ คือห้ามขี้โกงใช้ map ipv4 เป็น ipv6 ตรงๆ โดยเด็ดขาด

ฝั่ง web server ตรงนี้เป็น cluster ย่อมๆ เลย network ใช้ Virtual IP แต่ทำงานแบบ Dual Mode คือทุกเครื่องจะมีทั้ง Active VIP และ Standby VIP
โดยที่ Active VIP ของเครื่อง 1 จะเป็น Standby VIP ของเครื่อง 2 อย่างนี้ไปเรื่อยๆ
แล้วใช้ glusterfs ทำ replicate เก็บข้อมูล สามารถยัด node เพิ่มได้เรื่อยๆ ถ้าต้องการพื้นที่เพิ่ม

ปัญหาอย่างเดียวที่เจอตอนนี้คือ database ครับ … มัน… ทำงานพร้อมกันแบบ active-active ไม่ได้ T_T
ไม่สามารถใช้ master-master replication ได้ด้วยสาเหตุบางประการ เวลา master ล่ม จะ promote slave ขึ้นมาเป็น master แทนทันที
สามารถสลับเครื่องไปมาตลอด แต่ใช้ ip เดียว วิ่งผ่าน Virtual IP อันนึงครับ
อันนี้เขียน script ช่วยสลับเครื่องเพิ่มเติมไว้ด้วย ยังไม่รู้ว่าใช้งานจริงแล้วจะเน่าอนาถขนาดไหน

สรุป software ที่ใช้ (ในชุดทดสอบ)

- Linux CentOS 5.5 x86_64
- Apache 2.2 / PHP 5.2 / MySQL 5.0
- UCARP (Redundant Network Protocol)
- GlusterFS 3.0.5 (Distributed Storage Engine)
- Plesk 9.5 (Web Hosting Control Panel) ==> Concept ยังไม่ได้ทดสอบใช้งานจริง

จำนวนเครื่องในระบบขั้นต่ำ 4 เครื่อง แบ่งเป็น
- Web Server + Storage 2
- Database 2

ถ้าให้ดีขึ้นก็จับแยก storage ออกมาหน่อยจะดีมาก ด้านล่างเป็น diagram คร่าวๆ ครับ

กดดูแบบ hd & full screen นะครับ ไม่งั้นอ่านไม่ออกแน่ๆ (มือสั่นอย่างรุนแรง)

ข้อมูลจาก node th-inter ตัวที่ 1 “ตัวเดียว” ครับ ประมาณ 1/2 ของการใช้งานจากต่างประเทศ
ยกเว้นประเทศสิงคโปร์ และอเมริกา ที่ส่วนใหญ่จะไปเข้า local node

ก่อนอื่น… กราฟสวยๆ

ดูดีเนาะ 555+
การใช้งานส่วนใหญ่มาจากฝั่งเอเชียนี่เองครับ จีน ไต้หวัน ญี่ปุ่น เกาหลี ฮ่องกง เวียดนาม
ติด top 10 กันถ้วนหน้าเลยกับเว็บ upic.me (แหม่… ดีใจ 555)

ส่วน US ที่ติดมาสืบเนื่องจาก node us มันก็มาดึงข้อมูลจาก node นี้ไปอีกทีแหละครับ ฮาๆ

มาดูข้อมูลดิบกันบ้าง

จำนวนการเรียกใช้งานทั้งหมด 3,742,108 ครั้ง ในเวลา 22 ชั่วโมงโดยประมาณ
แยกเป็นประเทศได้ตามนี้ (หน่วยเป็น byte นะครับ)

China => 202,095,141,780
Taiwan => 30,763,908,755
Japan => 14,640,094,095
Australia => 7,493,311,135
Korea => 7,468,662,887
Hong Kong => 6,542,781,622
Norway => 4,919,033,297
Vietnam => 3,853,647,397
United States => 3,124,140,435
Indonesia => 1,951,024,078
Lao People’s Democratic Republic => 1,766,248,579
Philippines => 1,704,711,565
Singapore => 1,337,961,045
Sweden => 1,107,215,911
Saudi Arabia => 999,220,699
Egypt => 868,521,618
New Zealand => 723,835,429
Netherlands => 632,524,618
Switzerland => 617,493,578
Spain => 526,749,286
India => 514,174,899
Romania => 441,918,501
Denmark => 426,992,184
Russian Federation => 421,435,931
Satellite Provider => 361,535,996
Brazil => 349,569,983
Macao => 320,394,255
Poland => 309,159,056
Peru => 285,441,537
Mexico => 280,519,642
Belgium => 271,067,356
Finland => 228,320,020
Cambodia => 218,235,864
Israel => 207,022,815
Qatar => 201,281,637
Ireland => 182,970,473
Turkey => 181,759,920
Chile => 173,441,405
Iran => 171,209,368
Portugal => 156,470,473
Mongolia => 151,870,726
Austria => 140,058,698
Argentina => 134,664,927
Hungary => 110,891,007
Bulgaria => 107,699,820
Colombia => 106,465,842
Venezuela => 105,622,605
Morocco => 87,054,948
Kuwait => 66,969,144
Brunei Darussalam => 66,926,526
Greece => 65,023,869
Myanmar => 64,619,894
Latvia => 63,662,660
Germany => 54,857,294
Kazakhstan => 54,557,312
Iceland => 50,645,677
United Kingdom => 50,472,042
Pakistan => 49,128,446
Sri Lanka => 47,442,564
Anonymous Proxy => 44,293,355
South Africa => 40,663,825
Tunisia => 39,690,111
Croatia => 38,689,539
Slovenia => 37,174,011
Costa Rica => 35,742,173
Slovakia => 34,062,566
Oman => 33,970,500
Panama => 30,140,865
Ecuador => 28,924,437
Syrian Arab Republic => 27,284,402
Serbia => 27,167,138
Bhutan => 26,489,490
Sudan => 25,870,512
Jordan => 25,649,128
Mauritius => 25,299,294
Puerto Rico => 24,150,921
Algeria => 21,960,035
Lithuania => 21,290,085
Palestinian Territory => 20,965,637
Bahrain => 20,053,995
Libyan Arab Jamahiriya => 19,502,854
Bolivia => 19,148,809
France => 19,042,514
Estonia => 18,837,829
Dominican Republic => 16,682,118
Yemen => 15,454,628
Iraq => 15,210,516
Paraguay => 15,003,142
Azerbaijan => 14,008,267
Angola => 13,663,817
Bangladesh => 13,235,630
Madagascar => 13,095,413
Guatemala => 12,847,665
Cyprus => 12,464,925
Luxembourg => 11,510,883
Nepal => 11,459,579
Trinidad and Tobago => 11,336,978
Guam => 10,297,892
Malta => 10,271,033
El Salvador => 9,751,282
Maldives => 9,657,324
Faroe Islands => 9,549,256
Nigeria => 9,429,125
N/A => 9,086,745
Northern Mariana Islands => 8,964,550
Cote d’Ivoire => 8,395,061
Albania => 7,060,391
Georgia => 6,486,080
Uruguay => 5,978,795
Tanzania => 5,792,166
Macedonia => 5,462,526
Jamaica => 5,446,743
Cayman Islands => 5,300,771
Virgin Islands => 5,047,478
Ukraine => 4,682,547
Moldova => 4,588,322
Bosnia and Herzegovina => 4,265,196
Italy => 3,669,517
Greenland => 3,634,035
Congo => 3,537,780
Lebanon => 3,513,405
Chad => 3,050,376
Ghana => 2,974,198
Senegal => 2,702,979
Mozambique => 2,453,999
Nicaragua => 2,411,013
Belarus => 2,358,961
Kenya => 2,189,134
Honduras => 2,178,059
Anguilla => 2,069,787
Gabon => 1,959,629
Guyana => 1,716,600
Kyrgyzstan => 1,650,110
Rwanda => 1,630,538
Satellite Provider => 1,614,305
Mauritania => 1,564,111
Cameroon => 1,562,752
Tajikistan => 1,351,951
French Polynesia => 1,286,239
Bahamas => 1,272,910
Bermuda => 1,168,327
Namibia => 1,122,896
Equatorial Guinea => 968,711
Ethiopia => 964,567
Samoa => 928,088
Czech Republic => 901,837
Uzbekistan => 838,534
Liechtenstein => 780,715
Suriname => 763,885
Satellite Provider => 761,500
New Caledonia => 723,001
Aruba => 689,709
Jersey => 631,052
Djibouti => 611,903
Seychelles => 598,085
Uganda => 577,081
Mali => 551,049
Zimbabwe => 520,859
Burkina Faso => 484,435
Fiji => 481,484
Armenia => 465,542
Aland Islands => 431,218
Botswana => 425,821
Saint Vincent and the Grenadines => 324,732
Asia/Pacific Region => 304,056
Cook Islands => 237,992
Papua New Guinea => 209,561
Barbados => 156,931
Belize => 137,707
Gibraltar => 132,739
Grenada => 110,107
Satellite Provider => 104,744
Reunion => 85,409
Montenegro => 82,144
Saint Kitts and Nevis => 70,953
Antigua and Barbuda => 21,244
Saint Lucia => 12,181
Monaco => 11,461

#!/usr/bin/perl
# $Revision: 2 $
# $Date: 2008-09-12 15:11:40 +0300 (Fri, 12 Sep 2008) $
 
my %opt = (
# http link to nginx stub_status, be sure turn on stub_status in nginx conf
    nginx_status   => 'http://localhost:80/status',
# path for program what may dump web page, normaly lynx -dump
#    lynx            => 'lynx -dump',
    lynx            => 'wget -q -Y off -O -',
);
 
$opt{var} = $ARGV[0] if $ARGV[0];
$opt{nginx_status} = $ARGV[1] if $ARGV[1] and $ARGV[1]=~/^http:\/\/\w+/;
$opt{var} ||= '';
 
my $do = `$opt{lynx} $opt{nginx_status}`;
 
if ($opt{var} eq 'req') {
    $do=~/^Active connections:\s*(\d+)\s*$/ms or warn "Error! Can't find data!\nIN :\n$do";
    $opt{d2} = $opt{d1} = $1;
}
elsif ($opt{var} eq 'con') {
    $do=~/^\s*(\d+)\s+(\d+)\s+(\d+)\s*$/ms or warn "Error! Can't find data!\nIN :\n$do";
    $opt{d2} = $opt{d1} = $3;
}
#elsif { $do=~/^Reading:\s+(\d+).*Writing:\s+(\d+).*Waiting:\s+(\d+)/; }
else {
    $opt{var} = 'ERROR';
    $opt{d2} = $opt{d1} = 0;
    warn "Error! Please read the help and set (req|con)\n";
}
 
print "$opt{d1}\n";
print "$opt{d2}\n";
#print "$opt{up}\n" if $opt{up};
print "Nginx $opt{var}\n";

เสร็จแล้วสั่ง
chmod a+x /root/bin/mrtg-nginx.pl
ให้รันได้

แล้วเอาไอ้นี่ไปใส่ใน nginx.conf ส่วนของ vhost นะครับ

location /status {
    stub_status on;
    access_log off;
}

แล้วก็… อันนี้เอาไปใส่ใน mrtg.cfg

Target[nginx.newconns]: `/root/bin/mrtg-nginx.pl con`
Title[nginx.newconns]: NGINX Connections
PageTop[nginx.newconns]: <H1>NGINX Connections</H1>
MaxBytes[nginx.newconns]: 10000000000
ShortLegend[nginx.newconns]: c/s
YLegend[nginx.newconns]: Conns / sec
LegendI[nginx.newconns]: In
LegendO[nginx.newconns]:
Legend1[nginx.newconns]: New inbound connections
Legend2[nginx.newconns]:
Options[nginx.newconns]: growright,nopercent
 
Target[nginx.requests]: `/root/bin/mrtg-nginx.pl req`
Title[nginx.requests]: NGINX Requests
PageTop[nginx.requests]: <H1>NGINX Requests</H1>
MaxBytes[nginx.requests]: 10000000000
ShortLegend[nginx.requests]: req
YLegend[nginx.requests]: Req
LegendI[nginx.requests]: In
LegendO[nginx.requests]:
Legend1[nginx.requests]: New inbound connections
Legend2[nginx.requests]:
Options[nginx.requests]: growright,nopercent,gauge

.

บริการ 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

เอาจริงๆ มันก็ไม่เชิง cloud หรอก แค่เปลี่ยนระบบจัดการข้อมูลใหม่นิดหน่อยเพื่อให้แก้ไขระบบได้สะดวกขึ้น
และเสี่ยงต่อการถูกโจมตีจนระบบล่มใช้งานไม่ได้ (DDoS) น้อยลง เนื่องจากการเข้าใช้งานเป็นไปในลักษณะนั้น

ผลงานรอบนี้ ขอยกความดีความชอบให้ @rtsp ได้เลยครับ ส่วนความผิดพลาดทั้งหลายผมขอน้อมรับไว้เอง
เนื่องด้วยยังอ่อนประสบการณ์เรื่องนี้พอดี T_T ทำให้ระบบร่วงไปประมาณ 30 นาที (ช่วง 17.30 – 18.00 น.)
(มีเวลาเตรียมงาน นับเป็นชั่วโมงก็ราวๆ 4-5 ชั่วโมง แทบไม่ได้ทดสอบอะไรระบบใหม่นี้เลย)

แต่ดูแล้ว ผลเป็นที่น่าพอใจ และปีหน้าไม่พลาดแล้วครับ cloud computing จงเจริญ

สถิติ:
ปริมาณ bandwidth peak 11.6 Mbps เมื่อ 18.05 น.โดยประมาณ (แทบจะทันทีที่ระบบกลับมาใช้ได้)
ปริมาณการร้องขอเข้าใช้งานสูงสุด ณ เวลานั้น 1200 ครั้ง ต่อวินาที โดยประมาณ
CPU ช่วงจังหวะสูงสุดใช้ประมาณ 3 Core เต็มๆ (เทียบจาก Core 2 Quad ความเร็ว 2.53 GHz)
RAM ใช้ไปประมาณ 2GB

ข้อมูลเชิงเทคนิค
Web Server: lighttpd 1.4.19
Server-Side Scripting: PHP 5.2.6
Database: MySQL 5.0.51
IDC: ServeNet

ปีหน้าเอา atom server มารันดีมั้ยเนี่ย :D

ว่าแต่… แรงจริงเรอะ (ฮาาาาา)

วิธีการติดตั้งด้านล่างเป็นวิธีสำหรับ OS เปล่าๆ หรือไม่มี control panel เท่านั้นครับ
หากมี control panel อยู่จะไม่สามารถใช้งานได้ เพราะมันตีกัน

ส่วนไฟล์ มันมีแต่ของ centos 5 x86_64 นะครับ OS อื่นหนูไม่รู้ววว์

dkim-milter-2.8.3-2.el5.x86_64.rpm
dk-milter-1.0.2-0.x86_64.rpm

prepare yourself!

ก่อนอื่น ลบ MTA ทั้งหมดที่มีทิ้ง ไม่ว่าจะเป็น sendmail postfix exim qmail อะไรก็ตามแต่
แล้วลงแค่ postfix ใหม่ๆ เลย

yum install postfix sendmail
chkconfig sendmail off
chkconfig postfix on
service sendmail stop
service postfix start
rpm -Uvh dk-milter-1.0.2-0.x86_64.rpm dkim-milter-2.8.3-2.el5.x86_64.rpm
usermod -g 89 dkim-milter
chkconfig dkim-milter on
chkconfig dk-milter on
chown postfix.postfix /usr/sbin/dkim-filter
chown postfix -R /etc/mail/dkim-milter/keys
rm -f /var/run/dkim-milter/dkim-milter.sock

แก้ config !!!

เปิดไฟล์ /etc/mail/dkim-milter/dkim-filter.conf
หา # AuthservID example.com
เอา comment ออก แล้วแก้ example.com เป็นชื่อ domain เช่น yourdomain.com

แล้วเลื่อนลงมาอีกหน่อย หา # Domain example.com
เอา comment ออก ลบ example.com ทิ้ง แล้วใส่รายการ domain ที่ต้องการให้ sign DKIM (ถ้ามีหลาย domain ก็ใส่ , คั่น)

เลื่อนลงมาอีก หา Selector my-selector-name
แก้ my-selector-name เป็น default

เสร็จไป 1 ไฟล์ (ยังเหลืออีกบาน ฮาๆ)

ทีนี้… เปิดไฟล์ /etc/mail/dkim-milter/keys/keylist
ใส่ข้อมูลตามนี้

*@example.com:example.com:/etc/dkim-milter/example.com/default

อย่าลืมแก้ example.com เป็นชื่อ domain ที่ต้องการ sign ด้วยนะครับ
ถ้ามีหลาย domain ก็ใส่บรรทัดละ 1 domain

เปิดไฟล์ /etc/sysconfig/dkim-milter
เอา comment หน้า บรรทัด # EXTRA_FLAGS=-bs ออก แล้วก็เซฟ

เปิดไฟล์ /etc/init.d/dkim-milter
หาบรรทัดที่เขียนว่า user=${name} (ปกติจะอยู่บรรทัดที่ 19)
แก้เป็น user=postfix

เปิดไฟล์ /etc/sysconfig/dk-milter

#USER=”dk-milt”
#PORT=”local:/var/run/dk-milter/dk.sock”
#SIGNING_DOMAIN=”example.com”
#SELECTOR_NAME=”default”
#KEYFILE=”/etc/mail/domainkeys/dk_${SIGNING_DOMAIN}.pem”
#SIGNER=yes
#VERIFIER=yes
#CANON=simple
#REJECTION=”bad=r,dns=t,int=t,no=a,miss=r”
#EXTRA_ARGS=”-h -l -D”
#MILTER_GROUP=”mail”

เอา comment ออกให้หมด
แก้ตัวแดงบรรทัด SIGNING_DOMAIN เป็นโดเมนหลักที่ต้องการ sign
แก้ตัวแดงบรรทัด SELECTOR_NAME เป็น private
แก้ตัวแดงบรรทัด MILTER_GROUP เป็น postfix

DKIM sign

มา gen key สำหรับ sign DKIM กัน

mkdir -p /etc/dkim-milter/example.com/
cd /etc/dkim-milter/example.com/
dkim-genkey -d example.com
mv default.private default
chown postfix -R /etc/dkim-milter/

เหมือนเดิมนะครับ มีกี่โดเมนก็แก้ชื่อโดเมนทำให้ครบด้วย

ทีนี้หลังจาก gen แล้ว ใน folder ของแต่ละโดเมนจะมี file ชื่อ default.txt อยู่
ข้างในจะเป็น DNS record ที่เราต้องเอาไปเพิ่มเข้าใน DNS ของ domain นั้นๆ
สั่ง cat ดูได้เลยครับ (ถ้าใช้ bind ก็ก๊อปแปะใน zone file ได้เลย)

DomainKeys sign

มา gen key สำหรับ sign DomainKeys กัน

cd /etc/mail/domainkeys/
/usr/share/doc/dk-milter-1.0.2/gentxt.sh private example.com
mv private.private dk_example.com.pem

แก้จุดสุดท้าย
เปิดไฟล์ /etc/postfix/main.cf
ลงมาล่างสุดของไฟล์ เพิ่มไอ้นี่ลงไป

smtpd_milters = unix:/var/run/dkim-milter/dkim-milter.sock unix:/var/run/dk-milter/dk.sock
non_smtpd_milters = unix:/var/run/dkim-milter/dkim-milter.sock unix:/var/run/dk-milter/dk.sock

เซฟ ปิด แล้วสั่ง

rm -f /var/run/dkim-milter/dkim-milter.sock
chown postfix -R /var/run/dkim-milter
service dkim-milter restart
service dk-milter restart
service postfix restart

ฝั่ง server เรียบร้อย ทีนี้ก็ client ถ้าจะส่ง mail..
มีข้อแนะนำในการส่งประมาณนี้

1. reverse dns ของ ip ของ mail server ต้องชี้มายัง domain เดียวกันกับที่ใช้ส่ง
2. ทำ SPF Record ให้เรียบร้อย
3. DomainKeys + DKIM ตามวิธีด้านบน
4. ในเนื้อหา mail ต้องมีระบุข้อความว่า ให้ยกเลิกการรับข่าวสาร email ได้ที่ไหน
5. ใส่ header List-Unsubscribe ที่ชี้ไปยัง URL หรือ email ที่สามารถส่งไปขอยกเลิกการรับ mail ได้
6. การขอยกเลิกการรับข่าวสาร อนุญาตให้มีได้แค่ปุ่มยืนยันการยกเลิกเท่านั้น
7. ตั้ง Sender กับ Return-Path ให้รับ mail ได้ เพื่อไว้รอรับ mail ตีกลับ
8. ลบ email ที่ถูกตีกลับออกจากรายการ mail ที่ใช้ส่งตลอดเวลา
9. ไม่ส่ง mail เนื้อหาเดียวกันซ้ำๆ กัน
10. [สำหรับส่งเข้า yahoo] http://help.yahoo.com/l/us/yahoo/mail/postmaster/forms_index.html เข้าไปแล้วเลือก Yahoo! Mail Bulk Sender Form กรอกให้ครบ