การสร้างคลัสเตอร์เว็บเซิร์ฟเวอร์

<![CDATA[

การสร้างคลัสเตอร์เว็บเซิร์ฟเวอร์
1.1 DNS round robin
1.2 Application Load Balancing
1.3 HTTP redirecting
1.4 Virtual IP addressing

วิธีสร้างคลัสเตอร์เว็บเซิร์ฟเวอร์ ที่นิยมทำกันมีดังต่อไปนี้
1.1 DNS Round Robin

        ตามธรรมดา ชื่อเครื่อง 1 ชื่อ จะแปลงเป็นหมายเลขไอพี ได้ 1 เบอร์ เช่น www.ku.ac.th จะมีหมายเลขไอพีเป็น 158.108.2.71 แต่ในกรณีที่เราต้องการใช้จำนวนเว็บเซิร์ฟเวอร์ มากกว่า 1 เครื่องมาช่วยกันทำงาน เราสามารถ เพิ่มจำนวนเครื่องขึ้นมาได้ โดยแก้ที่ DNS server ให้แจกหมายเลขไอพี จำนวนหนึ่งเรียงตามลำดับ เช่น www.yahoo.com มีหมายเลขไอพี 204.71.200.74, 204.71.200.75, 204.71.200.67, 204.71.200.68 ซึ่งมีมากกว่า 1 หมายเลข เป็นไปได้ว่ามีเว็บเซิร์ฟเวอร์มากกว่า 1 เครื่องช่วยกันทำงาน หรืออย่าง www.cnn.com มีหมายเลข ไอพีมากกว่า 20 หมายเลข !

        โดยวิธีนี้ DNS แจกหมายเลข IP เรียงตามลำดับกันไป เพียงแต่เพิ่มจำนวนเว็บเซิร์ฟเวอร์โดยให้ข้อมูลในทุกเซิร์ฟเวอร์ เหมือนกันหมด และเพิ่มหมายเลขไอพีของแต่ละเซิร์ฟเวอร์ลงใน DNS server ดังนี้

จากเดิม
www     IN     HINFO     "www.ku.ac.th"
            IN      A     158.108.2.71

สมมุติว่าเราเพิ่มจำนวนเว็บเซิร์ฟเวอร์ขึ้นอีก 2 เครื่อง (158.108.2.72, 158.108.2.73)

www     IN      HINFO     "www.ku.ac.th"
             IN      A     158.108.2.71   
             IN      A     158.108.2.72
             IN      A     158.108.2.73

 

 

 

 

 

 

 

ภาพที่ 1 วิธี DNS Round Robin

 

        เมื่อผู้ใช้ คนที่ 1 เปิดบราวเซอร์ และต้องการเข้าถึงข้อมูลที่อยู่ภายใน http://www.ku.ac.th ตัวบราวเซอร์จะ ถาม DNS server เพื่อแปลงจาก ชื่อเป็นหมายเลขไอพี DNS server จะตอบกลับเป็น IP หมายเลข 158.108.2.71

        จากนั้นเมื่อผู้ใช้คนต่อมา ต้องการเข้าถึงข้อมูลเดียวกัน ตัวบราวเซอร์ของผู้ใช้คนต่อมา จำเป็นต้องถาม DNS server เพื่อแปลงจาก ชื่อเป็นหมายเลขไอพี เช่นเดียวกันกับบราวเซอร์ของผู้ใช้คนแรก คราวนี้ DNS server จะตอบกลับเป็น IP ถัดมา ซึ่งก็คือ 158.108.2.72

        สำหรับผู้ใช้คนที่สาม ก็เช่นเดียวกัน DNS server จะตอบกลับเป็น 158.108.2.73 และหลังจากนี้เมื่อมีผู้ใช้ คนต่อมา DNS server จะวนกลับและตอบกลับเป็น 158.108.2.71

        จะเห็นได้ว่า DNS server เป็นส่วนสำคัญสำหรับวิธีนี้ ซึ่งทำให้เป็นข้อด้อยของวิธีนี้ด้วยเช่นกัน พิจารณาจากการทำงานของ DNS ในความเป็นจริง (ดังภาพที่ 2)

 

 

 

 

 

 

 

        จะเห็นได้ว่าวิธีนี้นิยมทำกันมากเนื่องจากสามารถทำได้ง่าย และไม่ต้องการซอฟท์แวร์เพิ่มเติม เพียงแค่เพิ่มจำนวนเซิร์ฟเวอร์ และเพิ่มหมายเลขไอพีลงใน DNS server เท่านั้น

       จากภาพที่ 1 เรามีเว็บเซิร์ฟเวอร์จำนวน 3 เครื่อง (มีชื่อเดียวกัน คือ http://www.ku.ac.th หมายเลข IP คือ 158.108.2.71, 158.108.2.72 และ 158.108.2.73) โดยที่ทั้งสามมีข้อมูลเหมือนกันทุกอย่าง 

 

 

 

 ภาพที่ 2 แสดงการทำงานของ DNS sever

ปัญหาเกิดจาก DNS server ที่ผู้ใช้ติดต่อด้วย (Local DNS server) หลังจากที่ได้หมายเลขไอพีมาแล้ว จะเก็บหมายเลข IP นั้นเอาไว้จนกว่าจะถึงเวลาที่กำหนด (TTL) จึงจะลบออก หากมีผู้ใช้รายอื่นที่ต้องการติดต่อเว็บเดียวกัน และใช้ DNS server ตัวเดียวกันกับผู้ใช้คนแรก ตัว DNS server นั้นก็จะนำหมายเลขไอพีที่เก็บไว้มาให้ โดยไม่ไปถามจาก DNS server หลัก ทำให้ทั้งผู้ใช้คนแรก และของผู้ใช้คนที่สอง ติดต่อไปยังเซิร์ฟเวอร์ตัวเดียวกัน ทำให้การเฉลี่ยการใช้งานของเซิร์ฟเวอร์ทำได้ไม่ดีนัก

        อาจแก้ปัญหาโดยการลดเวลา TTL ลง แต่ส่วนใหญ่แล้ว Local DNS server เมื่อได้รับค่า TTL ที่ต่ำเกินไป จะไม่สนใจ และใช้ค่าปกติ นอกจากนั้นแล้วในส่วนของตัว browser ก็ยังมีการเก็บหมายเลขไอพีเอาไว้ด้วย เนื่องจากมีความเป็นไปได้ว่า ผู้ใช้จะยังต้องดึงข้อมูลจากเว็บเซิร์ฟเวอร์นั้นเพิ่มเติมอีกในอนาคต ดังนั้นการแก้ปัญหาโดยวิธีนี้นั้นไม่สามารถแก้ปัญหาได้

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

 

1.2 Application load balancing

        ในความเป็นจริง ข้อมูลที่เก็บไว้ในเว็บเซิร์ฟเวอร์จะประกอบด้วย ข้อมูลทั้งในแบบ static page (ข้อมูลที่ไม่มีการเปลี่ยนแปลง) และ dynamic page (ข้อมูลที่เปลี่ยนแปลงตลอดเวลา เช่น ข้อมูลการเคลื่อนไหวของค่าเงิน) ซึ่งข้อมูลในส่วนของ dynamic page นั้นมักจะเกี่ยวข้องกับการเข้าถึงฐานข้อมูล ซึ่งเป็นกระบวนการที่ใช้การทำงานของเซิร์ฟเวอร์มาก

 

 

ภาพที่ 3 วิธี Application Load Balancing

        จากภาพที่ 3 วิธีนี้จะแยกการทำงานของเซิร์ฟเวอร์ออกเป็นสองส่วน โดยในส่วนของ static page นั้นจะให้เว็บเซิร์ฟเวอร์หลัก จัดการค้นหา และส่งข้อมูลกลับ แต่หากว่าเป็นข้อมูลที่เป็น dynamic page (CGI/ASP) ตัวเซิร์ฟเวอร์หลัก จะส่งต่อไปให้เซิร์ฟเวอร์ตัวอื่น ที่ทำหน้าที่ด้านนั้นโดยเฉพาะ (ซึ่งอาจเป็นเครื่องที่มีความเร็วสูงกว่า)

        ซึ่งวิธีนี้จะดีกว่าการใช้เซิร์ฟเวอร์เพียงตัวเดียว ทำทั้งสองหน้าที่ และช่วยลดเวลาตอบสนองของทั้งระบบลงได้มาก

        นอกจากการแบ่งเป็น static page และ dynamic page แล้วในบางวิธี จะรวมถึงการแบ่ง static page ออกเป็นหลายส่วน ในกรณีที่ข้อมูลมีเป็นจำนวนมหาศาล (เช่น ในระบบของ search engine – altavista, yahoo มีการแบ่งข้อมูลกระจายเก็บไว้ในหลายเซิร์ฟเวอร์ หากมีเซิร์ฟเวอร์ใดเซิร์ฟเวอร์หนึ่งเกิดปัญหา ก็จะยังมีข้อมูลอื่นๆ ในเซิร์ฟเวอร์ตัวอื่น เพราะในระบบ search engine นั้น ผลลัพธ์ที่ค้นได้ อาจมีปริมาณมากมาย จนสามารถตัดบางส่วนทิ้งไปได้)

        ตัวอย่างเช่น ในระบบ pWEB [1] ประกอบด้วยระบบ ดังภาพที่ 4

 

ภาพที่ 4 การทำงานของ pWEB

        โดยใน Forward Node จะทำหน้าที่รับ คำร้องขอจากผู้ใช้ จากนั้นส่งผ่านไปให้ Server ต่างๆ ตา
มที่ได้กำหนดไว้ โดยใน Forward Node จะมีโปรแกรมเล็กๆ ชื่อว่า Forwarding Agent และในแต่ละเซิร์ฟเวอร์จะมีโปรแกรมเล็กๆ ชื่อว่า Receive Agent

        โดยเมื่อ Forward Node รับคำร้องขอเข้ามา Forwarding Agent จะทำหน้าที่ส่งคำร้องขอ ไปยัง Receive Agent บนเซิร์ฟเวอร์ที่กำหนดไว้กับคำร้องขอนั้น จากนั้นเมื่อ Receive Agent บนเซิร์ฟเวอร์ได้รับคำร้องขอ จาก Forwarding Agent จะส่งผ่านให้โปรแกรมเว็บเซิร์ฟเวอร์ที่อยู่บนเซิร์ฟเวอร์เดียวกันกับมัน เมื่อเว็บเซิร์ฟเวอร์ทำงานเสร็จ จะส่งผลลัพธ์ที่ได้ให้ Receive Agent จากนั้น Receive Agent จะส่งกลับไปให้ Forwarding Agent เพื่อตอบกลับไปยังผู้ใช้ต่อไป

โดย Forwarding Agent มีหลักในการส่งคำร้องขอดังนี้

 

ภาพที่ 5 แสดงการปรับแต่งบนตัว Forwarding Agent

        ในระบบเว็บเซิร์ฟเวอร์ คำร้องขอจะอยู่ในรูปแบบของคำสั่ง “GET” ตามด้วยแฟ้มข้อมูลที่ต้องการ เช่น “GET /index.html” , “GET /cgi-bin/querydb.cgi”

        จากภาพที่ 5 หมายความว่า คำร้องขอที่นำหน้าด้วย “/” และ “/gifs/logo” จะถูกส่งไปยัง Receive Agent บน server1 , นำหน้าด้วย “/gifs” จะถูกส่งไปยัง Receive Agent บน server2 และนำหน้าด้วย “/cgi-bin” จะถูกส่งไปยัง server3 และ server4 สลับกัน

        ตัวอย่างของระบบที่ใช้วิธีนี้ เช่น NonStop WebCharger 1.0A+ (Tandem) [3] โปรแกรมนี้จะเป็นส่วนเพิ่ม (add-on) ของโปรแกรมเว็บเซิร์ฟเวอร์ Internet Information Server (IIS) – Microsoft เมื่อมีคำร้องเป็น static page ระบบจะส่งไปให้โปรแกรม IIS แต่ถ้าหากมีคำร้องที่เป็น dynamic page (ASP, CGI) ระบบจะส่งไปให้เซิร์ฟเวอร์ตัวอื่นที่ทำหน้าที่ด้านนั้นโดยเฉพาะ

 

1.3 HTTP Redirect

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

        ตัวเซิร์ฟเวอร์หลักจะต้องมีการตรวจเช็คปริมาณงานในเซิร์ฟเวอร์ทุกตัวที่มีอยู่ทุกระยะ และเก็บเอาไว้ เมื่อผู้ใช้ส่งคำร้องขอ มายังเซิร์ฟเวอร์หลัก ตัวเซิร์ฟเวอร์หลักจะส่งคำร้องขอไปให้เซิร์ฟเวอร์ตัวที่มีปริมาณงานน้อยที่สุดในขณะนั้นเสมอ โดยวิธีที่ใช้ส่งคำร้องคือ การใช้ HTTP redirect ซึ่งก็คือการที่เซิร์ฟเวอร์สั่งให้ browser ของผู้ใช้ ติดต่อไปยังเซิร์ฟเวอร์ตัวอื่น โดยที่ผู้ใช้ไม่ต้องทำอะไร

 

ภาพที่ 6 วิธี HTTP Redirection

        จากภาพ สมมุติว่าในขณะนั้นเซิร์ฟเวอร์ที่มีหมายเลขไอพี 158.108.0.2 มีประมาณงานน้อยที่สุด ตัวเซิร์ฟเวอร์หลัก (158.108.0.1) จะสั่งให้ browser ของผู้ใช้ติดต่อไปยังเซิร์ฟเวอร์ 158.108.0.2 โดยอัตโนมัติ

     &
nbsp;  ลักษณะของคำสั่ง HTTP redirect tag จะเป็นดังนี้
        < meta http-equiv = "refresh" content = "0 ; url = http://158.108.0.2/index.html&quot; >

        ในอดีต browser บางตัวเท่านั้นที่สนับสนุน tag นี้ แต่คาดว่าในปัจจุบันจะสนับสนุนหมดทุกตัวแล้ว จาก tag ดังกล่าว หมายความว่า ให้ browser ติดต่อไปยัง URL – http://158.108.0.2/index.html โดยหน่วงเวลา 0 วินาที

        ตัวอย่างเช่น ในระบบ Scalable Web Server Architectures [2] ประกอบด้วยระบบ ดังนี้

ภาพที่ 7 การทำงานของ SWEB

        ในระบบนี้แต่ละเซิร์ฟเวอร์จะมีข้อมูลไม่เหมือนกัน โดยในเซิร์ฟเวอร์หลัก (www.lucent.com) จะมีหลักในการ redirect คำร้องขอ ดังนี้

Redirect /news/politics http://www1.lucent.com/news/politics
Redirect /news/weather http://www2.lucent.com/news/weather
Redirect /news/sports http://www3.lucent.com/news/sports

        จากตัวอย่างนี้ จะเหมือนกับแบบ Application Load Balancing และการกระจายงานก็จะได้ไม่ดีเท่า เราสามารถปรับให้ดีขึ้นได้ โดยเปลี่ยนให้ทุกเซิร์ฟเวอร์มีข้อมูลเหมือนกันหมด และให้เซิร์ฟเวอร์หลัก redirect โดยดูจากปริมาณงานในแต่ละเซิร์ฟเวอร์เป็นเกณฑ์ แทนที่จะเป็นแบบตายตัว โดยอาจดูจากปริมาณการใช้ หน่วยประมวลผลกลางในแต่ละเซิร์ฟเวอร์เป็นเกณฑ์ในการวัดปริมาณงาน

        ตัวอย่างของระบบที่ใช้วิธีนี้ เช่น ClusterCATS 1.1 (Bright Tiger Technologies) [3] โปรแกรมนี้จะเป็นส่วนเพิ่ม (add-on) ของโปรแกรมเว็บเซิร์ฟเวอร์ Internet Information Server (IIS) – Microsoft ระบบจะมีตัวเซิร์ฟเวอร์หลักที่ทำหน้าที่ redirect คำร้องขอไปให้เซิร์ฟเวอร์ตัวที่มีภาระน้อยที่สุด โดยแต่ละเซิร์ฟเวอร์จะต้องมีการ์ดเน็ทเวิร์คจำนวน 2 การ์ด เพื่อส่งข้อมูลระหว่างกันตลอดเวลา ในกรณีที่มีเซิร์ฟเวอร์ใดมีปัญหา เซิร์ฟเวอร์ตัวใดตัวหนึ่งจะต้องทำหน้าที่แทนโดยใช้ IP aliasing (การปลอมเป็นหมายเลขไอพีของเครื่องที่มีปัญหา) จนกว่าเซิร์ฟเวอร์ตัวที่มีปัญหาจะกลับมาทำงานต่อได้

 

1.4 Virtual IP addressing

        จากวิธี DNS round robin และ HTTP redirect เซิร์ฟเวอร์แต่ละตัว จำเป็นต้องมีหมายเลขไอพีจริง ซึ่งหากมีเซิร์ฟเวอร์ใดเซิร์ฟเวอร์หนึ่งมีปัญหา จะต้องมีการให้เซิร์ฟเวอร์ตัวใดตัวหนึ่งทำหน้าที่แทนโดยใช้วิธี IP aliasing นอกจากนั้นแล้วการใช้หมายเลขไอพีจริง จะทำให้ถูกก่อกวนจากภายนอกได้ง่าย

        ในวิธีนี้ เราจะใช้หมายเลขไอพีจริงเพียงเบอร์เดียวกับเซิร์ฟเวอร์หลัก (คล้ายกับวิธี Application Load Balancing) ส่วนเซิร์ฟเวอร์อื่นๆ เราจะใช้หมายเลขไอพีส่วนตัว ซึ่งไม่สามารถเข้าถึงจากภายนอกได้ (เช่น หมายเลขไอพีที่ขึ้นต้นด้วย 192.168. หรือ 10.)

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

 

แบบตอบกลับต้องผ่านตัวกลาง

ภาพที่ 8 วิธี Virtual IP แบบผ่านตัวกลาง

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

        การสร้างระบบ Virtual IP โดยผ่านตัวกลาง สามารถทำได้โดยแก้ไขในส่วนของการทำ masquerade ของ Linux          โดยให้เซิร์ฟเวอร์หลักทำหน้าที่แจกจ่ายคำร้องขอ และตอบกลับ โดยการแจกจ่ายอาจใช้วิธี round-robin หรือเลือกส่งให้เครื่องที่มีโหลดต่ำสุด โดยเครื่องนี้มีหมายเลขไอพีจริง ส่วนเซิร์ฟเวอร์ที่เหลือใช้หมายเลขไอพีส่วนตัว และออกแบบให้มี fault tolerant โดยเมื่อเซิร์ฟเวอร์ตัวกลางมีปัญหา จะให้เซิร์ฟเวอร์ตัวอื่นทำหน้าที่แทน จนกว่าตัวกลางจะกลับมาทำหน้าที่ได้เหมือนเดิม

  

แบบตอบกลับไม่ต้องผ่านตัวกลาง

ภาพที่ 9 วิธี Virtual IP แบบไม่ผ่านตัวกลาง

        จากภาพที่ 9 เมื่อเซิร์ฟเวอร์หลักได้รับ การร้องขอ จะส่งผ่านไปให้เซิร์ฟเวอร์ที่มีปริมาณงานน้อยที่สุด จากนั้นเมื่อได้ผมลัพธ์ เซิร์ฟเวอร์ตัวนั้นจะส่งกลับไปให้ผู้ใช้โดยตรง ซึ่งวิธีนี้จะเห็นได้ว่า แก้ปัญหาคอขวดของเซิร์ฟเวอร์หลัก เพราะเซิร์ฟเวอร์หลักทำหน้าที่ส่งผ่านเฉพาะข้อมูลขาเข้าเท่านั้น ส่วนข้อมูลขาออก เซิร์ฟเวอร์ที่ทำหน้าที่นั้นจะส่งกลับไปให้ผู้ใช้โดยตรง จากการที่ลักษณะของข้อมูลขาเขามีขนาดน้อยกว่าขอออกมาก (ขาเข้ามักจะมีรูปแบบ “GET ชื่อแฟ้มข้อมูล” ซึ่งมีขนาดเพียง 1 บรรทัด) ส่วนขาออกมักจะมีขนาดใหญ่กว่ามากเนื่องจาก เป็นข้อมูลในส่วนที่ผู้ใช้ร้องขอ

        ดังนั้นระบบที่ใช้วิธีการตอบกลับแบบไม่ผ่านตัวกลาง จะสามารถรองรับผู้ใช้ ได้มากกว่าระบบที่ใช้วิธีตอบกลับแบบผ่านตัวกลางมาก อย่างไรก็ตามระบบที่ใช้วิธีตอบกลับแบบผ่านตัวกลางสามารถสร้างได้ง่ายกว่า และรองรับปริมาณงานได้มากพอสมควร

 

แผนภาพแสดงการทำงานของระบบ

  

ภาพที่ 10 การทำงานของวิธี Virtual IP แบบไม่ผ่านตัวกลาง

        จากภาพที่ 10 เมื่อผู้ใช้ส่งคำร้องขอไปยังเซิร์ฟเวอร์หลัก (1) ตัวเซิร์ฟเวอร์หลักจะส่งผ่านคำร้องขอไปให้เซิร์ฟเวอร์ที่มีปริมาณงานน้อยที่สุด (2) เมื่อเซิร์ฟเวอร์ที่มีปริมาณงานน้อยที่สุด ได้รับคำร้องที่ส่งผ่านมาจะส่งผ่านคำร้องนั้นให้โปรแกรมเว็บเซิร์ฟเวอร์ ที่ทำงานอยู่บนเซิร์ฟเวอร์นั้น (3) จากนั้นผลลัพธ์ที่ได้จากเว็บเซิร์ฟเวอร์ จะถูกส่งไปให้ผู้ใช้โดยตรง (4)

        จะสังเกตุเห็นว่า ในทุกเซิร์ฟเวอร์จะมีโปรแกรม (Agent) ทำงานอยู่ ซึ่งหน้าที่ของโปรแกรมนี้ก็คือ แลกเปลี่ยนปริมาณงานในแต่ละเซิร์ฟเวอร์ ระหว่างกันเพื่อหาเซิร์ฟเวอร์ที่มีปริมาณงานต่ำที่สุด

        การสร้างระบบ Virtual IP โดยผ่านตัวกลาง สามารถทำได้โดยแก้ไขในส่วนของการทำ masquerade
ของ Linux โดยให้เซิร์ฟเวอร์หลักทำหน้าที่แจกจ่ายคำร้องขอ โดยการแจกจ่ายอาจใช้วิธี round-robin หรือเลือกส่งให้เครื่องที่มีโหลดต่ำสุด โดยเครื่องนี้มีหมายเลขไอพีจริง ส่วนเซิร์ฟเวอร์ที่เหลือใช้หมายเลขไอพีส่วนตัว ในการตอบกลับเครื่องที่ใช้หมายเลขไอพีส่วนตัว จะตอบกลับโดยเปลี่ยนหมายเลขไอพีต้นทางของแพกเก็ต เป็นหมายเลขไอพีจริงของเซิร์ฟเวอร์หลัก จากนั้นระบบจำเป็นต้องมี fault tolerant โดยเมื่อเซิร์ฟเวอร์ตัวกลางมีปัญหา จะให้เซิร์ฟเวอร์ตัวอื่นทำหน้าที่แทน จนกว่าตัวกลางจะกลับมาทำหน้าที่ได้เหมือนเดิม

ตัวอย่างของระบบที่ใช้วิธีนี้ เช่น Convoy Cluster 2.03 (Valence Research) [3] โปรแกรมนี้จะเป็นส่วนเพิ่ม (add-on) ของโปรแกรมเว็บเซิร์ฟเวอร์ Internet Information Server (IIS) – Microsoft ระบบจะทำงานโดยให้เซิร์ฟเวอร์ทุกตัว ใช้ MAC address เดียวกัน และในการตอบกลับจะใช้วิธีการตอบกลับโดยไม่ผ่านตัวกลาง ในกรณีที่มีเซิร์ฟเวอร์หลักมีปัญหา เซิร์ฟเวอร์ตัวใดตัวหนึ่งจะต้องทำหน้าที่แทนโดยใช้ IP aliasing (การปลอมเป็นหมายเลขไอพีของเครื่องที่มีปัญหา) จนกว่าเซิร์ฟเวอร์หลักจะกลับมาทำงานต่อได้

 

ภาพที่ 11 เปรียบเทียบการใช้หน่วยประมวลผลบนเซิร์ฟเวอร์แต่ละตัว

        จากภาพที่ 11 ในการทดสอบพบว่าโปรแกรมสามารถกระจายงานให้เซิร์ฟเวอร์ทุกเครื่องได้ในปริมาณที่ใกล้เคียงกัน (โดยดูจากปริมาณการใช้งานของหน่วยประมวลผลกลางในแต่ละเซิร์ฟเวอร์ จะเห็นว่าใกล้เคียงกันมาก)

]]>