Sorachat ChaithaneeNE...ระบบเฝ าระว งและตรวจสอบการท างานของอ เมลเซ ร ฟเวอร Email Server Monitoring

i

ระบบเฝ้าระวังและตรวจสอบการท างานของอีเมลเซิรฟ์เวอร์

Email Server Monitoring System

สรชัช ชัยธานี Sorachat Chaithanee

สารนพินธ์นี้เป็นส่วนหน่ึงของการศึกษา

หลักสูตรวิทยาศาสตรมหาบัณฑิต สาขาวิชาวิศวกรรมเครือขา่ย

คณะวิทยาการและเทคโนโลยีสารสนเทศ

มหาวิทยาลยัเทคโนโลยมีหานคร

ปีการศึกษา 2560

ii

หัวข้อ ระบบเฝ้าระวังและตรวจสอบการท างานของอีเมลเซิร์ฟเวอร์

Email Server Monitoring System

ชื่อนักศึกษา นายสรชัช ชัยธานี

รหัสนักศึกษา 5617660026

หลักสูตร วิทยาศาสตรมหาบัณฑิต สาขาวิศวกรรมเครือข่าย

ปีการศึกษา 2560

อาจารย์ท่ีปรึกษา ผศ.ดร.สุรณพีร์ ภูมิวุฒิสาร

บทคัดย่อ

สารนิพนธ์ฉบับนี้เป็นการน าเสนอ การพัฒนาโปรแกรมเพ่ือน ามาใช้ในการแก้ปัญหาระบบเฝ้า

ระวังและตรวจสอบการท างานของอีเมลเซิร์ฟเวอร์ ที่มีข้อจ ากัดของบริษัท เซิร์ฟเวอร์ทูเดย์ (ประเทศ

ไทย) จ ากัด กล่าวคือ การท างานของระบบเดิม ไม่สามารถทราบปัญหากรณีเกิดเหตุการณ์เซอร์วิสตัว

ใดตัวหนึ่งหยุดท างานหรือท างานล้มเหลว แบบปัจจุบันขณะ (Real time) ซึ่งจะส่งผลให้ผู้ใช้งาน เข้า

ใช้งานอีเมลไม่ได้ และผู้ดูแลระบบจะไม่ทราบจนกว่าจะมีการโทรมาแจ้งปัญหา

การพัฒนานี้จะได้น า Software Module มาใช้เป็นส่วนประกอบ โดยระบบใหม่จะเป็น

ระบบเฝ้าระวังแบบรวมศูนย์ ซึ่งสามารถแสดงผลข้อมูลภาพรวม ตีความได้ง่าย โดยข้อมูลที่ได้เป็น

แบบปัจจุบันขณะ (Real time) พร้อมระบบแจ้งเตือนกรณีเซอร์วิสหยุดท างานผ่าน อีเมล และ line

จากนั้นเจ้าหน้าที่สามารถส่งค าสั่ง Restart service จากระบบนี้ได้ทันที ซึ่งจะช่วยเพ่ิมความต่อเนื่อง

ของการให้บริการ สามารถเฝ้าระวังและตรวจสอบการท างานของเซอร์วิสส าคัญของ Zimbra ได้

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

ทันเวลา และสามารถแก้ไขปัญหาได้อย่างทันท่วงที

จากการน าระบบเฝ้าระวังและตรวจสอบการท างานของอีเมลเซิร์ฟเวอร์ พบว่า ผู้ใช้งานระบบ

สามารถทราบการท างานของเซอร์วิสได้ก่อน ท าให้แก้ไขปัญหาได้อย่างทันท่วงที และสามารถ

ประหยัดเวลาในการต้องเฝ้าระวังแบบเดิมได้ดียิ่งขึ้น เนื่องจากสามารถดูได้จากภาพรวม ไม่ต้องดู

หลายๆ หน้าจอ

iii

กิตติกรรมประกาศ

การจัดท าสารนิพนธ์เล่นนี้ ส าเร็จลุล่วงไปได้ด้วยดีเนื่องจากผู้จัดท าได้รับค าแนะน าที่ดีและค า

ติชมที่เป็นประโยชน์ต่อการท าสารนิพนธ์จากท่าน ผศ.ดร.สุรณพีร์ ภูมิวุฒิสาร ซึ่งเป็นอาจารย์ที่ปรึกษา

อาจารย์ณัฏฐ์ มาเจริญ อาจารย์ที่ปรึกษาร่วมและอาจารย์ทุกท่านที่ได้มีส่วนร่วมในสารนิพนธ์เล่มนี้

รวมถึงอาจารย์ทุกท่านที่เป็นคณะกรรมการสอบที่ได้แสดงความคิดเห็นติชมและแนะน าเพ่ือมาเป็น

แนวทางในการท าสารนิพนธ์และทดสอบระบบจนลุล่วงไปได้ด้วยดี สุดท้ายนี้บุคคลที่มีพระคุณอัน

ยิ่งใหญ่ที่มิอาจลืมได้คือ บิดา-มารดา ที่คอยเอาใจใส่และเป็นก าลังใจให้อยู่เสมอ ส่งผลให้สารนิพนธ์

เล่มนี้ส าเร็จลุล่วงไปได้ด้วยดี ผู้จัดท าสารนิพนธ์จึงขอขอบพระคุณทุกท่านไว้ ณ ที่นี้

สรชัช ชัยธานี มิถุนายน 2561

iv

สารบัญ หน้า

บทคัดย่อ i กิตติกรรมประกาศ ii สารบัญ iii สารบัญรูป v สารบัญตาราง vii บทที่ 1 บทน า 1

1.1 ความเป็นมาของโครงงาน 1 1.2 ระบบที่น าเสนอ 2

1.3 วัตถุประสงค์ของโครงงาน 2 1.4 ขอบเขตของการศึกษาค้นคว้า 2 1.5 ประโยชน์ที่จะได้รับ 4 1.6 แผนการด าเนินงาน 4 บทที่ 2 พ้ืนฐานและทฤษฎีที่เกี่ยวข้อง 6 2.1 ระบบอีเมล 6

2.2 โปรแกรม Zimbra Collaboration 8 2.3 ระบบบริหารจัดการเครือข่าย (Network Management System: NMS) 9

2.4 Simple Network Management Protocol 11 2.5 Management Information Base (MIB) 16

บทที่ 3 การออกแบบระบบและพัฒนาระบบ 18 3.1 กล่าวน า 18 3.2 ระบบงานที่น าเสนอ 18

3.3 ขั้นตอนในการพัฒนาระบบ 20 3.4 Flowchart การท างานของระบบ 21 3.5 ต้นแบบโครงร่าง (Prototype Design) 29 บทที่ 4 ผลการทดลอง 31 4.1 กล่าวน า 31 4.2 เครื่องมือที่ใช้ในการทดลองและสภาพแวดล้อม 31

4.3 ขั้นตอนการท างานและการทดสอบระบบ 31 4.4 การทดสอบก าหนดข้อมูลระบบ 32 บทที ่5 สรุปผลการด าเนินงาน 45 5.1 ผลการด าเนินงานโครงงาน 45 5.2 ปัญหาและอุปสรรค 45

v

สารบัญ (ต่อ) หน้า

5.3 ข้อเสนอแนะและแนวทางในการพัฒนาในอนาคต 45 เอกสารอ้างอิง 46

vi

สารบัญรูป

หน้า รูปที่ 1.1 โครงสร้างของระบบเฝ้าระวังและตรวจสอบสถานะการท างานของอีเมลเซิร์ฟเวอร์ 2 รูปที่ 2.1 แสดงส่วนประกอบของสถาปัตยกรรมจดหมายอิเล็กทรอนิกส์ 7 รูปที่ 2.2 แสดงแผนภาพแสดงการไหลของข้อความอีเมลบนอินเตอร์เน็ต 7 รูปที่ 2.3 แสดงเซอร์วิสที่เป็นองค์ประกอบส าคัญของโปรแกรม Zimbra 8 รูปที่ 2.4 แสดงสถาปัตยกรรมการจัดการเครือข่าย 10 รูปที่ 2.5 องค์ประกอบของโปรโตคอลเอสเอ็นเอ็มพี 12 รูปที่ 2.6 แสดง SNMP Community 15 รูปที่ 2.7 แสดงความสัมพันธ์ระหว่าง Manager and Agent 16 รูปที่ 3.1 ภาพรวมของระบบเฝ้าระวังและตรวจสอบสถานะการท างานของอีเมลเซิร์ฟเวอร์ 18 รูปที่ 3.2 แสดงแผนภาพการท างานของระบบแจ้งเตือนอัตโนมัติ 21 รูปที่ 3.3 แสดงแผนภาพการท างานของ 22 รูปที่ 3.4 แสดงแผนภาพการท างานของโปรแกรมแจ้งเตือนอัตโนมัติ 23 รูปที่ 3.5 แสดงแผนภาพการท างานของโปรแกรม Remote Command 24 รูปที่ 3.6 แสดงแผนภาพแสดงความสัมพันธ์ระหว่างข้อมูล 25รูปที่ 3.7 แสดงหน้า Login เข้าสู่ระบบ 29 รูปที่ 3.8 แสดงหน้า Dashboard 29 รูปที่ 3.9 แสดงหน้า Monitor Resource 30 รูปที่ 4.1 รูปหน้าจอการเข้าใช้งานระบบ 32 รูปที่ 4.2 รูปแสดงผลการเข้าสู่ระบบส าเร็จ 32 รูปที่ 4.3 รูปหน้าจอหลักของระบบ (Dashboard) 32 รูปที่ 4.4 แสดงข้อมูลการเพ่ิมเซิร์ฟเวอร์ใหม่ 34 รูปที่ 4.5 แสดงรายชื่อของ Zimbra เซิร์ฟเวอร์ ที่อยู่ในระบบ 34 รูปที่ 4.6 รูปหน้าจอหลักของระบบ (Dashboard) 35 รูปที่ 4.7 รูปแสดงหน้าจอรายละเอียดสถานะของ Zimbra เซิร์ฟเวอร์ 35 รูปที่ 4.8 แสดงหน้าจอเพ่ิมข้อมูลบัญชีผู้ใช้งานใหม่ 36 รูปที่ 4.9 แสดงหน้าจอการก าหนดสิทธิ์การเข้าใช้งานของบัญชีผู้ใช้งาน 36 รูปที่ 4.10 แสดงหน้าจอการเข้าสู่ระบบของบัญชีผู้ใช้งานใหม่ 37 รูปที่ 4.11 แสดงผลการเข้าสู่ระบบของผู้ใช้งานใหม่ส าเร็จ 37 รูปที่ 4.12 แสดงผลเกณฑ์การตรวจสอบทรัพยากรระบบก่อนปรับค่า 38 รูปที่ 4.13 แสดงสถานะของการใช้งาน Memory ก่อนทดสอบ 38 รูปที่ 4.14 แสดงสถานะรายละเอียดของการใช้งาน Memory ก่อนทดสอบ 39

vii

สารบัญรูป (ต่อ)

หน้า รูปที่ 4.15 แสดงผลเกณฑ์การตรวจสอบทรัพยากรระบบหลังปรับค่าเพ่ือทดสอบ 39 รูปที่ 4.16 แสดงสถานะของการใช้งาน Memory หลังทดสอบ 40 รูปที่ 4.17 แสดงสถานะและรายละเอียดของการใช้งาน Memory หลังทดสอบ 40 รูปที่ 4.18 แสดงผลการตรวจสอบ Disk บนเครื่อง Zimbra เซิร์ฟเวอร์ 40 รูปที่ 4.19 แสดงผลการตรวจสอบ Disk บนโปรแกรม 41 รูปที่ 4.20 แสดงผลการตรวจสอบสถานะเซอร์วิส amavis บนเครื่อง Zimbra เซิร์ฟเวอร์ 41 รูปที่ 4.21 แสดงผลการตรวจสอบสถานะเซอร์วิส amavis บนโปรแกรม 41 รูปที่ 4.22 แสดงผลการตรวจสอบ Disk บนโปรแกรม 42 รูปที่ 4.23 ข้อความอีเมลแจ้งเตือนจากระบบ 42รูปที่ 4.24 ข้อความจากระบบ Line Notify 42 รูปที่ 4.25แสดงผลการตรวจสอบพบเซอร์วิส Amavis หยุดท างาน 43 รูปที่ 4.26 ข้อความอีเมลแจ้งเตือนจากระบบ 43 รูปที่ 4.27 ข้อความจากระบบ Line Notify 44 รูปที่ 4.28 แสดงผลการตรวจสอบพบเซอร์วิส amavis หยุดท างาน 44 รูปที่ 4.29 แสดงผลการปรับสถานะของ amavis 44

viii

สารบัญตาราง

หน้า ตารางที ่1 ตารางการด าเนินงานโครงงาน 1 4 ตารางที ่2 ตารางการด าเนินงานโครงงาน 2 5 ตารางที่ 3.1 tbl_server เก็บข้อมูลเซิร์ฟเวอร์ 25 ตารางที่ 3.2 tbl_ram_usage เก็บข้อมูลหน่วยความจ า 26 ตารางที่ 3.3 tbl_cpu1_usage เก็บข้อมูล Load Average ของเซิร์ฟเวอร์ 26 ตารางที่ 3.4 tbl_swap_usage เก็บข้อมูลหน่วยความจ าชั่วคราว (ดิสก์) 26 ตารางที่ 3.5 tbl_disk_usage เก็บข้อมูลหน่วยความจ า 26 ตารางที่ 3.6 tbl_zimbra_status เก็บข้อมูลสถานะของเซอร์วิส Zimbra 27 ตารางที่ 3.7 tbl_severity_zimbra เก็บข้อมูลเกณฑ์การประเมินสถานะของเซอร์วิส Zimbra 27 ตารางที่ 3.8 tbl_severity_zimbra เก็บข้อมูลเกณฑ์การประเมินสถานะของทรัพยากรระบบ 27 ตารางที่ 3.9 tbl_login เก็บข้อมูลบัญชีผู้ใช้งาน 28 ตารางที่ 3.10 tbl_policy เก็บข้อมูลเงื่อนไขการเข้าใช้งาน 28 ตารางที่ 3.11 tbl_main_menu เก็บข้อมูลเมนูหลัก 28 ตารางที่ 3.12 tbl_sub_menu เก็บข้อมูลเมนูหลัก 29

ix

บทที่ 1 บทน า

1.1 ความเป็นมาของโครงงาน อีเมลเป็นเครื่องมือสื่อสารหลักส าหรับธุรกิจในยุคปัจจุบัน ความพร้อมใช้งานของอีเมล

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

บริษัท เซิร์ฟเวอร์ทูเดย์ (ประเทศไทย) จ ากัด [1] ด าเนินธุรกิจหลักเป็นผู้ให้บริการอีเมล

ส าหรับองค์กรธุรกิจ ภายใต้อีเมลซอร์ฟแวร์ชื่อ Zimbra Collaboration ประกอบไปด้วยเซอร์วิสต่างๆ ในการใช้งาน และจะมีเจ้าหน้าที่ท าการเฝ้าระวังผ่านเครื่องมือของโปรแกรม Zimbra จากการศึกษาพบว่าเครื่องมือดังกล่าว มีข้อจ ากัดที่เป็นปัจจัยส าคัญต่อการให้บริการ กล่าวคือ เครื่องมือเฝ้าระวังที่มากับระบบไม่เหมาะกับการใช้งานในการให้บริการแก่ผู้ใช้บริการจ านวนมาก เนื่องจากการท างานสามารถดูได้ครั้งละ 1 ต่อ 1 เท่านั้น

ปัญหาที่พบ คือ กรณีเกิดเหตุการณ์เซอร์วิสตัวใดตัวหนึ่งหยุดท างานหรือท างานล้มเหลว จะ

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

ผู้ศึกษาจึงมีแนวคิดที่จะท าการพัฒนาระบบเฝ้าระวังและตรวจสอบสถานะการท างานของ

อีเมลเซิร์ฟเวอร์ เพ่ือให้ได้ระบบเฝ้าระวังและตรวจสอบสถานะการท างานที่ครอบคลุมทุกองค์ประกอบที่ส าคัญของอีเมลเซิร์ฟเวอร์ ผู้ศึกษาคาดว่าระบบนี้จะสามารถอ านวยความสะดวกให้ผู้ดูแลรับทราบข้อมูล สามารถแก้ไขปัญหา และช่วยลดผลกระทบที่จะเกิดต่อผู้ใช้งานได้อย่างทันท่วงทีโดยการพัฒนานี้จะได้น า Software Module มาใช้เป็นส่วนประกอบในการพัฒนาระบบต่อไป

1.2 ระบบที่น าเสนอ

1.2.1 ผู้ศึกษาจะท าการศึกษาแนวคิดและทฤษฎีที่เกี่ยวข้องกับระบบเฝ้าระวังและตรวจสอบสถานะการท างานของอีเมลเซิร์ฟเวอร์ จากนั้นจะน าแนวคิดที่ได้มาประกอบการออกแบบระบบเฝ้าระวังและตรวจสอบสถานะการท างานของ Zimbra อีเมลเซิร์ฟเวอร์ โดยการประยุกต์ใช้ภาษา PHP ฐานข้อมูล MySQL และ Shell Script

x

1.2.2 ผู้ศึกษาจะน าระบบเฝ้าระวังและตรวจสอบสถานะการท างานของอีเมลเซิร์ฟเวอร์ที่ได้ จากการพัฒนา ไปทดสอบกับระบบอีเมลเซิร์ฟเวอร์จ าลอง ที่ท างานภายใต้ซอร์ฟแวร์ Zimbra Collaboration เวอร์ชั่น 8.7 รุ่น Open Source Edition บนระบบปฏิบัติ การ Ubuntu 14.04LTS รูปแบบการติดตั้งแบบ Single Server แล้วท าการสรุปผลการศึกษาและพัฒนา

1.3 วัตถุประสงค์ของโครงงาน

1.3.1.1 เพ่ือศึกษาแนวคิด และทฤษฎีที่ เกี่ยวข้องกับระบบเฝ้าระวังและตรวจสอบสถานะการท างานของอีเมลเซิร์ฟเวอร์

1.3.1.2 เพ่ือออกแบบ และพัฒนาระบบมอนิเตอร์สถานะการท างานของอีเมลเซิร์ฟเวอร์ ที่มีคุณสมบัติดังนี้

1.3.2.1 สามารถแสดงสถานะการท างานของเซอร์วิสบนอีเมลเซิร์ฟเวอร์ได้ 1.3.2.2 สามารถแจ้งเตือนผู้ดูแลระบบเมื่อเซอร์วิสหยุดท างาน ผ่านช่องทางอีเมล

และแอพพลิเคชั่นไลน์

1.4 ขอบเขตของการศึกษาค้นคว้า

ผู้ศึกษาจะท าการออกแบบและพัฒนาระบบเฝ้าระวังและตรวจสอบสถานะการท างานของอีเมลเซิร์ฟเวอร์ บนโครงสร้างจ าลองบนซอร์ฟแวร์ชื่อ Zimbra Collaboration โดยระบบที่ออกแบบจะท างานในลักษณะ Web Application และมีโครงสร้างการท างานของระบบ ดังรูปที่ 1.1

รูปที่ 1.1 แสดงโครงสร้างของระบบเฝ้าระวังและตรวจสอบสถานะการท างานของอีเมลเซิร์ฟเวอร์

xi

คุณสมบัติของระบบเฝ้าระวังและตรวจสอบสถานะการท างานของ Zimbra อีเมลเซิร์ฟเวอร์ การพัฒนาระบบเฝ้าระวังและตรวจสอบสถานะการท างานของ Zimbra อีเมล์เซิร์ฟเวอร์ ผู้ศึกษาได้ก าหนดคุณสมบัติอันประกอบด้วย ความสามารถในด้านการตรวจสอบสถานะการใช้งานทรัพยากรของระบบ ความสามารถในด้านการตรวจสอบสถานะการท างานของเซอร์วิสส าคัญของZimbra การก าหนดเกณฑ์ (threshold) หรือระดับของความรุนแรงของความผิดปกติของการใช้งานทรัพยากรระบบ ระบบแจ้งเตือน ความสามารถในการส่งค าสั่ง Restart service ไปยังเครื่องเซิร์ฟเวอร์ปลายทาง ระบบบริหารจัดการบัญชีผู้ใช้งาน และระบบบริหารจัดการเครื่องเซิร์ฟเวอร์ ส่วนรายละเอียดความสามารถในแต่ละด้านมีดังนี้

1. สามารถตรวจสอบสถานะการใช้งานทรัพยากรต่างๆ ของระบบได้ดังนี้ 1.1 ข้อมูล Load Average 1.2 ข้อมูลการใช้งานหน่วยความจ า (RAM) 1.3 ข้อมูลการใช้งานพื้นที่ดิสก์ท่ีใช้เป็นหน่วยความจ าส ารอง (SWAP) 1.4 ข้อมูลการใช้งานพื้นที่ดิสก์ (DISK)

2. สามารถตรวจสอบสถานะการท างานของเซอร์วิสส าคัญของ Zimbra ในด้านต่างๆ ดังนี้2.1 เซอร์วิส amavis 2.2 เซอร์วิส ldap 2.3 เซอร์วิส mailboxd 2.4 เซอร์วิส mta 2.5 เซอร์วิส proxy 2.6 เซอร์วิส memcache 2.7 เซอร์วิส configd

3. สามารถก าหนดเกณฑ์ (threshold) หรือระดับของความรุนแรงของความผิดปกติของการใช้งานทรัพยากรระบบในข้อ 4.2 ได ้3 ระดับ คือ

3.1 สถานะปกติ (Normal) หมายถึงระบบท างานอยู่ในเกณฑ์ปกติ 3.2 สถานะเฝ้าระวัง (Warning) หมายถึง ระบบท างานอยู่ในเกณฑ์ท่ีมีความเสี่ยงที่จะเกิด

ความผิดพลาด ผู้ดูแลระบบต้องท าการตรวจสอบก่อนเกิดปัญหา 3.3 สถานะวิกฤติ (Critical) – ระบบท างานอยู่ในเกณฑ์ท่ีเกิดความผิดพลาดต้องได้รับการ

แก้ไขเร่งด่วน 4. มีระบบแจ้งเตือนหากมีการใช้งานทรัพยากรระบบเกินกว่าค่าที่ก าหนดไว้ หรือเซอร์วิสของ

Zimbra หยุดท างาน (Stopped) โดยสามารถส่งข้อความแจ้งเตือนไปให้ผู้ดูแลระบบได้ 2 ช่องทาง คือ ส่งอีเมล และแจ้งข้อความแจ้งเตือนไปยังกลุ่มไลน์ของผู้ดูแลระบบได้ในทันที

xii

5. ในกรณีที่ระบบเฝ้าระวังพบว่ามีเซอร์วิสของ Zimbra หยุดท างาน ระบบสามารถส่งค าสั่ง Restart service ไปยังเครื่องเซิร์ฟเวอร์ปลายทางได้ทันที

6. มีระบบบริหารจัดการบัญชีผู้ใช้งาน สามารถเพ่ิมหรือลบบัญชีผู้ใช้งานได้ และสามารถก าหนดสิทธิ์การเข้าถึงระบบในแต่ละส่วนได้

7. มีระบบบริหารจัดการเครื่องเซิร์ฟเวอร์ สามารถเพ่ิมหรือลบเซิร์ฟเวอร์ที่ต้องการเฝ้าระวังได ้

1.5 ประโยชน์ที่จะได้รับ 1.5.1 ได้ระบบเฝ้าระวังแบบรวมศูนย์ ซึ่งสามารถแสดงผลข้อมูลภาพรวม ตีความได้ง่าย

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

1.5.2 ช่วยเพ่ิมความต่อเนื่องของการให้บริการ สามารถเฝ้าระวังและตรวจสอบการท างานของเซอร์วิสส าคัญของ Zimbra ได้ตลอดเวลา

1.5.3 ช่วยให้ผู้ดูแลระบบทราบถึงสถานการณ์ท างานของอีเมลเซิร์ฟเวอร์ได้แบบทันเวลา และสามารถแก้ไขปัญหาได้อย่างทันท่วงที

1.6 แผนการด าเนินงาน

แผนการด าเนินงานแบ่งเป็น 2 โครงงาน โดยเป็นการด าเนินงานแบบต่อเนื่อง รายละเอียดตามตารางที ่1.1 และ 1.2

ตารางที ่1.1 ตารางการด าเนินงานโครงงาน 1

แผนการท างานแต่ละสัปดาห์ ส.ค. 2560

ก.ย. 2560

ต.ค. 2560

พ.ย. 2560

ธ.ค. 2560

1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1. ศึกษาข้อมูลภาพรวมและสภาพ

ปัญหา

2. ศึกษาแนวคิดและทฤษฎีที่เกี่ยวข้อง

3. น าเสนอหัวข้อโครงงาน

4. วิเคราะห์ ออกแบบระบบ

5. จัดท าเอกสารการออกแบบระบบ

6. น าเสนอโครงงาน 1

xiii

ตารางที ่1.2 ตารางการด าเนินงานโครงงาน 2

แผนการด าเนินงานในแต่ละสัปดาห์ ม.ค. 2561

ก.พ. 2561

มี.ค. 2561

เม.ย. 2561

พ.ค. 2561

1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1. พัฒนาระบบตามเอกสารการ

ออกแบบ

2. ทดสอบและเก็บผลการทดลอง

3. จัดท าเอกสารประกอบโครงงาน 2

4. น าเสนอโครงงาน 2

xiv

บทที่ 2 พื้นฐานและทฤษฎีที่เกี่ยวข้อง

2.1 ระบบอีเมล

Forouzan, Behrouz A. [3] ได้อธิบายหลักการของระบบอีเมล (Electronic Mail) ว่าเป็นบริการรับส่งจดหมายผ่านเครือข่ายคอมพิวเตอร์ เช่นเครือข่ายอินเตอร์เน็ตซึ่งให้บริการได้สะดวกและรวดเร็วกว่าการใช้บริการไปรษณีย์ธรรมดามาก สามารถรับส่งข่าวสารได้ทั้งแบบตัวอักษร ภาพ และเสียง ท าให้การติดต่อสื่อสารไม่มีขีดจ ากัด และเป็นระบบที่ได้รับความนิยมในการใช้บริการสูงในเครือข่าย

2.1.1 สถาปัตยกรรมของระบบอีเมล ระบบอีเมลท างานบนสถาปัตยกรรมซอร์ฟแวร์แบบไคลเอ็นต์ เซิร์ฟเวอร์ซึ่ง

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

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

กรอบการท างานของระบบอีเมลจะประกอบด้วย 3 องค์ประกอบส าคัญ คือ 1. Agents คือ ส่วนของโปรแกรมที่ท าหน้าที่ด าเนินการแทนผู้ใช้งานหรือท า

หน้าที่แทนโปรแกรมอ่ืน 2. Mail store คือ ส่วนจัดเก็บข้อความอีเมลของแต่ละบัญชีผู้ใช้งาน 3. Standard คือ มาตรฐานหรือข้อก าหนดในการจัดการข้อความ เช่น วิธีการ

จัดรูปแบบข้อความ การเข้ารหัส รูปแบบการจัดส่งข้อความและการเข้าถึงข้อความอีเมลเป็นต้น ทั้งนี้ ข้อความอีเมลจะถูกจัดการโดยโปรแกรม Agent ที่ท าหน้าที่แตกต่างกัน 3

ประเภท คือ 1. MUA (Mail User Agent) หรือที่เรียกว่าโปรแกรมรับส่งอีเมล เป็นโปรแกรม

ที่ท างานบนฝั่งไคลเอ็นท์หรือฝั่งผู้ใช้งาน ท าหน้าที่ช่วยให้ผู้ใช้งานสามารถอ่าน เขียนและส่งข้อความอีเมลได้อย่างสะดวก ตัวอย่างเช่น โปรแกรม Microsoft Outlook, Thunderbird, Eudora และ Zimbra Desktop เป็นต้น

xv

2. MTA (Mail Transport Agent) เป็นโปรแกรมที่ท างานบนฝั่งอีเมลเซิร์ฟเวอร์ ท าหน้าที่ส่งและรับข้อความอีเมลระหว่างอีเมลเซิร์ฟเวอร์ หรือ MTA ตัวอ่ืน ตัวอย่างโปรแกรมที่ท าหน้าที่MTA เช่นZimbra (Postfix), Exim, Sendmail, Qmail, Microsoft Exchange เป็นต้น

3. MDA (Mail Delivery Agent) เป็นโปรแกรมที่ท างานบนฝั่งอีเมลเซิร์ฟเวอร์ ท าหน้าที่รับข้อความอีเมลต่อจาก MTA แล้วจัดส่งข้อความอีเมลไปยังระบบภายในหรือเขียนบันทึกข้อความอีเมลไปยังกล่องจดหมายของผู้รับภายใน (Mailstore) ตัวอย่างโปรแกรมที่ท าหน้าที่ MDA เช่น Procmail, Maildrop Postfix เป็นต้น

รูปที่ 2.1 แสดงส่วนประกอบของสถาปัตยกรรมจดหมายอิเล็กทรอนิกส์

รูปที่ 2.1 แสดงให้เห็นเส้นทางการไหลของข้อความอีเมลบนอินเตอร์เน็ต โดยข้อความจะเริ่มจากผู้ส่งจนไปถึงผู้รับโดยผ่านแต่ละองค์ประกอบ โดยเริ่มจาก MUA ฝั่งผู้ส่ง (Sender’s MUA) ท าหน้าที่ในการรวบรวมข้อความอีเมลจากผู้ส่งจากนั้นท าการส่งข้อความต่อไปที่ MTA ฝั่งผู้ส่ง (Sender mail server) จากนั้น MTA ฝั่งผู้ส่งท าการตรวจสอบและระบุเส้นทางพร้อมจัดส่งข้อความอีเมลไปที่ MTA ฝั่งผู้รับ (Receiver mail server) เมื่อ MTA ฝั่งผู้รับได้รับข้อความอีเมลก็ท าการตรวจสอบพบว่าเป็นผู้ใช้ภายในเซิร์ฟเวอร์ จึงท าการส่งข้อความอีเมลไปที่ MDA เมื่อ MDA ได้รับข้อความจึงท าการส่งข้อมูลไปบันทึกไว้ภายในแหล่งจัดเก็บข้อมูลอีเมลของบัญชีผู้รับ (Mail store) และขั้นตอนสุดท้ายของกระบวนการคือ ผู้รับอีเมลสามารถเปิดอ่านข้อความ MUA ทั้งนี้จะเห็นได้ว่า MUA จะเป็นทั้งต้นทางและปลายทางของอีเมล

รูปที่ 2.2 แสดงแผนภาพแสดงการไหลของข้อความอีเมลบนอินเตอร์เน็ต

xvi

การไหลของข้อความอีเมลในรูปที่ 2.2 มีการใช้มาตรฐานและโปรโตคอลการรับส่งข้อความอีเมลบนอินเตอร์เน็ต โดยก่อนที่ข้อความก่อนจะถูกส่งออกไปจะต้องได้รับการจัดรูปที่แบบและเข้ารหัสตามมาตรฐาน Internet Message Format และส่วนขยาย MIME (Multipurpose Internet Mail Extensions) โปรโตคอล SMTP คือ โปรโตคอลมาตรฐานที่ใช้เพ่ือขนส่งข้อความอีเมล ขณะที่ POP3 และ IMAP4 เป็นโปรโตคอลมาตรฐานในการเข้าถึงข้อความอีเมล โปรโตคอลทั้งหมดเหล่านี้ถูกใช้ภายใน Agent ที่เกี่ยวข้อง โดยเฉพาะอย่างยิ่ง MUA จะใช้โปรโตคอล SMTP, POP3 และ IMAP4 ในขณะที่ภายใน MTA และ MDS ใช้โปรโตคอล SMTP

2.2 โปรแกรม Zimbra Collaboration

Synacor, Inc. [5] ได้กล่าวว่า Zimbra เป็นโปรแกรมอีเมลที่ท างานบนฝั่งเซิร์ฟเวอร์ ได้รับการพัฒนาครั้งแรกโดย LiquidSys ซึ่งต่อมาได้เปลี่ยนชื่อเป็น Zimbra, Inc. ในวันที่ 26 กรกฎาคม 2548 มีให้เลือกใช้งานสองรุ่น คือ เวอร์ชั่นโอเพ่นซอร์ส และเวอร์ชั่นลิขสิทธิ์ หรือ Network Edition จุดเด่นของ Zimbra คือมีฟังก์ชั่นหลากหลายและใช้งานง่าย

2.2.1 สถาปัตยกรรมของโปรแกรม Zimbra โปรแกรม Zimbra ถูกพัฒนาขึ้นด้วยเทคโนโลยีโอเพ่นซอร์สที่ได้รับความนิยมและ

ท างานบนโปรโตคอลมาตรฐาน ถูกพัฒนาขึ้นบนพ้ืนฐานของเทคโนโลยีโอเพ่นซอร์สและโปรโตคอลมาตรฐานที่ได้รับความนิยมหลายตัว ทั้งบนฝั่งอินเทอร์เฟซฝั่งผู้ใช้งาน โดยมีส่วนประกอบหลักบนฝั่งเซิร์ฟเวอร์ดังแสดงในรูปที่ 2.3

รูปที่ 2.3 แสดงเซอร์วิสที่เป็นองค์ประกอบส าคัญของโปรแกรม Zimbra

xvii

2.2.2 องค์ประกอบส าคัญของโปรแกรม Zimbra Zimbra Collaboration มีแพคเกจแอ็พพลิ เคชันที่แสดงอยู่ ใน เซอร์วิสที่ เป็น

องค์ประกอบส าคัญของโปรแกรม Zimbra แสดงดังนี้

• Mailboxd ท าหน้าที่เป็นศูนย์กลางการควบคุมระบบและจัดการข้อความอีเมลบนกล่องจดหมายของผู้ใช้งานทั้งหมดรวมถึงข้อความสมุดติดต่อปฏิทิน และไฟล์แนบ

• LDAP ท าหน้าที่พิสูจน์ตัวตนของผู้ใช้งาน (user authentication) รวมถึงเป็นองค์ประกอบส าคัญของการก าหนดคุณลักษณะต่างๆ (configuration) บน Zimbra เซิร์ฟเวอร ์

• MTA ท าหน้าที่ในการรับและส่งข้อความอีเมลบนโปรโตคอล smtp จากอีเมลเซิร์ฟเวอร์ (MTA) หรือโปรแกรมอีเมลฝั่งผู้ใช้งาน (MUA)

• Amavis - ท าหน้าที่ติดต่อสื่อสารระหว่าง MTA กับโมดูลที่ท าหน้าที่คัดกรองเนื้อหาอีเมลเช่น Clam AntiVirus (ClamAV) และ SpamAssassin

• ClamAV ท าหน้าที่ป้องกันไวรัสโดยการสแกนเนื้อหาอีเมลและไฟล์แนบที่มากับอีเมล

• SpamAssassin ท าหน้าที่คัดกรองสแปมอีเมลตามกฎการจับคู่เนื้อหา โดยใช้เทคนิคการตรวจจับสแปมหลากหลาย

• Configd ท าหน้ าที่ จั ดการกับการ เปลี่ ยนแปลงการตั้ ง ค่ าคุณลั กษณะ (configuration) ขององค์ประกอบต่างๆ บน Zimbra เซิร์ฟเวอร ์

• Proxy ท าหน้าที่ควบคุมเส้นทางการเชื่อมต่อจากผู้ใช้งานผ่านโปรโตคอล IMAP, POP, HTTP ไปยังบริการอ่ืนๆ ของ Zimbra เพ่ิมประสิทธิภาพ และความปลอดภัยให้กับ Zimbra เซิร์ฟเวอร ์

• Memcached ท าหน้าที่เป็นหน่วยความจ าส ารองเพ่ือเพ่ิมประสิทธิภาพให้กับ Proxy

2.3 ระบบบริหารจัดการเครือข่าย (Network Management System) Cisco System [6] ได้บรรยายถึงองค์ความรู้ด้านการบริหารจัดการเครือข่ายเอาไว้ว่า

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

2.3.1 สถาปัตยกรรมการจัดการเครือข่าย สถาปัตยกรรมการจัดการเครือข่ายส่วนใหญ่ ใช้โครงสร้างพ้ืนฐานและชุดของ

ความสัมพันธ์เดียวกัน โดยประกอบไปด้วย

xviii

• Managed Devices หรื อ อุปกรณ์ เครื อข่ ายที่ ถู กจั ดการ เช่น ระบบคอมพิวเตอร์และอุปกรณ์เครือข่ายอ่ืนๆ ถูกติดตั้งซอฟต์แวร์ที่ช่วยให้อุปกรณ์สามารถส่งการแจ้งเตือนไปยัง Management entities เมื่อพบปัญหา (ตัวอย่างเช่นเมื่อมีการเกินเกณฑ์ท่ีผู้ใช้ก าหนดไว้)

• Management entities ยังสามารถส่ง query ไปยังอุปกรณ์เครือข่ายที่ถูกจัดการ เพ่ือตรวจสอบค่าของตัวแปรบางตัว การส่ง query ไปยังอุปกรณ์เครือข่ายที่ถูกจัดการ สามารถด าเนินการโดยอัตโนมัติ หรือ สามารถเริ่มด าเนินการก่อนจากฝั่งผู้ใช้ แต่ agent ในอุปกรณ์ที่ถูกจัดการจะท าการตอบกลับทุก query

• Agents เป็นโมดูลซอฟต์แวร์ที่ติดตั้งอยู่ภายในอุปกรณ์เครือข่าย ท าหน้าที่รวบรวมข้อมูลเกี่ยวกับอุปกรณ์ที่ถูกจัดการ จากนั้นเก็บข้อมูลนี้ในฐานข้อมูลการจัดการ และท าหน้าที่ใ ห้ ข้ อมู ลทั้ ง เ ชิ ง รุ กและ เชิ ง รั บ ( proactively or reactively) ไปยั ง management entities (manager) ภายในระบบการจัดการเครือข่าย (NMS) ผ่านโปรโตคอลการจัดการเครือข่าย

• โปรโตคอลการจัดการเครือข่าย เป็นโปรโตคอลที่อยู่ใน Application Layer ของ Transmission Control Protocol/Internet Protocol (TCP/IP) ใช้ส าหรับแลกเปลี่ยนข้อมูลเกี่ยวกับการบริหารเครือข่ายระหว่างอุปกรณ์เครือข่ายต่างๆ ช่วยให้ผู้ดูแลระบบสามารถจัดการประสิทธิภาพ วิเคราะห์ปัญหา และให้ข้อมูลเพ่ือใช้ส าหรับการวางแผนเพ่ือการขยายเครือข่ายในอนาคต เช่น โปรโตคอล SNMP (Simple Network Management Protocol) และโปรโตคอล CMIP (Common Management Information Protocol)

• Management proxies คือ หน่วยงานที่ให้ข้อมูลการจัดการในนามของหน่วยงานอื่น

รูปที่ 2.4 แสดงสถาปัตยกรรมการจัดการเครือข่าย

xix

2.3.2 การจัดการเครือข่ายตามมาตรฐาน ISO องค์กรมาตรฐานระหว่างประเทศ (The International Organization for

Standardization) หรือ ISO ได้น าเสนอแบบจ าลองระบบบริหารจัดการเครือข่ายโดยแบ่งตามฟังก์ชั่นงานออกเป็น 5 ฟังก์ชั่น ดังนี้

1. การจัดการประสิทธิภาพ (Performance Management) มีเป้าหมายเพ่ือท าการวัดและจัดท าเกณฑ์ประสิทธิภาพของระบบเครือข่ายในมิติต่างๆ เพ่ือให้การท างานของระบบเครือข่ายท างานได้ดีในระดับที่ยอมรับได้

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

3. การจัดการบัญชี (Accounting Management) มีเป้าหมายเพ่ือจัดสรรการใช้ทรัพยากรในระบบเครือข่ายส าหรับบุคคลหรือกลุ่มบุคคลในเครือข่าย เพ่ือให้สามารถควบคุมปริมาณการใช้งานทรัพยากรได้อย่างเหมาะสม

4. การจัดการข้อบกพร่อง (Fault Management) มีเป้าหมายเพ่ือตรวจสอบข้อบกพร่อง ท าการบันทึกข้อมูลและแจ้งให้ผู้ใช้ทราบ รวมถึงท าการแก้ไขปัญหาเครือข่ายโดยอัตโนมัติ เพ่ือให้ระบบเครือข่ายท างานได้อย่างมีประสิทธิภาพ

5. การจัดการความปลอดภัย (Security Management) มีเป้าหมายเพ่ือควบคุมการเข้าถึงทรัพยากรเครือข่ายตามนโยบายขององค์กร เพ่ือไม่ให้ระบบเครือข่ายถูกท าลาย และเพ่ือให้ข้อมูลที่ละเอียดอ่อนไม่สามารถเข้าถึงได้โดยผู้ที่ไม่มีสิทธิ์

2.4 Simple Network Management Protocol

Charles Kozierok, [2] ได้กล่าวว่า Simple Network Management Protocol หรือ SNMP เป็น Network Management Protocol ที่ช่วยในการบริหารจัดการเครือข่ายได้จากศูนย์กลาง ถูกออกแบบในกลางปีทศวรรษ 1980 จุดมุ่งหมายแรกเพ่ือแก้ไขปัญหาการจัดการระหว่างเครือข่ายที่ยุ่งยาก

SNMP ในปัจจุบันเป็นที่นิยมใช้กันมากในระบบบริหารจัดการเครือข่าย โดยจะท า

หน้าที่ ในการสื่อสารระหว่างตัว Management Station (Manager) กับ Management Agent (Agent) ภายในระบบบริหารเครือข่าย SNMP เป็นโปรโตคอลที่อยู่ใน Application Layer ของ Transmission Control Protocol/Internet Protocol (TCP/IP) มีจุดมุ่งหมายให้ท างานกับ User Data Protocol (UDP) ทั้งนี้เนื่องจากการท างานของ UDP เป็นลักษณะแบบ Connectionless คือ

xx

ไม่ต้องมีการสร้าง Connection ก่อนที่จะส่งข้อมูล จึงสามารถส่งข้อมูลได้รวดเร็ว เหมาะส าหรับที่จะส่ง Message สั้น ๆ อย่าง Message ของ SNMP มากกว่า TCP

2.4.1 องค์ประกอบของโปรโตคอลเอสเอ็นเอ็มพี

1. เมเนเจอร์ (Manager) ท าหน้าที่ควบคุมดูแลการท างานของอุปกรณ์ต่างๆ ในเครือข่าย โดยส่งการร้องขอไปยังเอเจนต์และน าข้อมูลที่ได้นั้นมาแสดงผลการท างานของแต่ละอุปกรณ ์

2. เอเจนต์ (Agent) ท าหน้าที่รับการร้องขอข้อมูลจากเมเนเจอร์มาและท าการค้นหาสิ่งที่เมเนเจอร์ร้องขอแล้วส่งข้อมูล กลับไปยังเมเนเจอร์เพ่ือแสดงผลในการท างานต่อไป

3. เอสเอ็นเอ็มพีเมสเสจ (Message) ท าหน้าที่ส่งข้อมูลระหว่าง เมเนเจอร์และ เอเจนต์

4. Structure of Management Information เ อ ส เ อ็ ม ไ อ ( SMI) คื อ โครงสร้างของข้อมูลเพื่อการจัดการ รูปแบบโครงสร้างเป็นแบบแผนภูมิต้นไม้

5. Management Information Base (MIB) หรือ มิบ คือ ฐานข้อมูลของเอสเอ็นเอ็มพีของแต่ละอุปกรณ์

จากการกล่าวข้างต้นจะเห็นเป็นตัวอย่าง ดังรูปที่ 2.5

รูปที่ 2.5 องค์ประกอบของโปรโตคอลเอสเอ็นเอ็มพี

โปรโตคอล SNMP มีการพัฒนามาอย่างต่อเนื่อง เริ่มตั้งแต่ SNMPv1 จนถึงปัจจุบันคือ SNMPv3 โดยในเวอร์ชั่น 1 และ 2 นั้นมีลักษณะของสถาปัตยกรรมและการท างานที่คล้ายคลึงกัน แต่ในเวอร์ชั่น 3 ได้มีการยกระดับในด้านความปลอดภัยเพิ่มข้ึน

xxi

เวอร์ชั่นของ SNMP โปรโตคอล 1. SNMPv1 (RFC 1157) ฟังก์ชันพ้ืนฐานที่ได้รับความนิยมเนื่องจากความง่ายของ

โปรโตคอล รองรับบนอุปกรณ์เครือข่ายทุกค่าย ระดับความปลอดภัยของ SNMPv1 จะขึ้นอยู่กับคอมมิวนิตี้สตริง (Community String) ซึ่งท าหน้าที่เหมือนรหัสผ่าน โดยปกติคอมมิวนิตี้จะมีสามประเภท คือ อ่านอย่างเดียว (Read-only) อ่านเขียน (Read-write) และ แทรป (Trap)

2. SNMPv2 (RFC 1905, RFC 1906, RFC 1907) ออกแบบมาเพ่ือแก้ไขข้อด้อยของ SNMPv1 ในเรื่องการร้องขอข้อมูลปริมาณมากและปัญหาในการส่งข้อมูลแบบแทรป โดยการเพ่ิมค าสั่งส าหรับใช้ในการจัดการเครือข่าย เพ่ิมกลุ่มของอ๊อบเจ็คในฐานข้อมูล MIB เพ่ือยกระดับความสามารถและประสิทธิภาพของการท างาน

3. SNMPv3 ( FC1905, RFC1906, RFC1907, RFC2571, RFC2572, RFC2573, RFC2574, RFC2575) เป็นเวอร์ชั่นที่ถูกคาดหวังให้เป็นมาตรฐานที่สมบูรณ์ มุ่งเน้นการยกระดับความปลอดภัยของโปรโตคอล SNMP ให้มากขึ้นโดยการเพ่ิมฟังก์ชั่นที่ส าคัญ ๆ ดังนี้

3.1 Message Integrity เพ่ือให้แน่ใจว่าแพ็คเกตที่ส่งจะไม่ถูกเปลี่ยนแปลงหรือถูกท าลายระหว่างทาง

3.2 Authentication การตรวจสอบว่าข้อความได้มาจากแหล่งที่ถูกต้องจริงหรือไม ่

3.3 Encryption ท าการเข้ารหัสข้อมูลของเพ็คเกต เพ่ือป้องกันการถูกดักจับข้อมูลโดยแหล่งที่ไม่ได้รับอนุญาต

2.4.2 การท างานของเอสเอ็นเอ็มพีโปรโตคอล

การจัดการระบบเครือข่าย อุปกรณ์ทุกตัวต้องมีการสื่อสารโดยการแลกเปลี่ยนข่าวสารจ าเป็นต้องใช้ข้อความ ในการบรรจุข้อมูลและการจัดการ เพ่ือส่งไปยังปลายทาง การท างานของ เอสเอ็นเอ็มพีเวอร์ชั่น 1 ประกอบไปด้วย 5 ข้อความ คือ GetRequest, GetNextRequest, GetResponse, SetRequest และTrap ส่วนในเอสเอ็นเอ็มพีเวอร์ชั่น 2 เพิ่มเติมขึ้นอีก 2 ข้อความ คือ GetBulkRequest และ InformRequest เอสเอ็นเอ็มพีเวอร์ชั่น 3 เพ่ิม อีก 1 ข้อความ คือ Report นั่นเอง รายละเอียดของข้อความประกอบไปด้วย 8 ข้อความ ดังนี้

2.4.2.1 GetRequest เป็นข้อความที่เอ็มเอสส่งไปยังเอ็มเอ เพ่ือที่จะบอกว่าเอ็มเอส ต้องการทราบข้อมูลอะไรบ้างจากเอ็มเอ

2.4.2.2 GetNextRequest เป็นข้อความที่ส่งกลับมาจากเอ็มเอจะไม่ใช้ข้อมูลของออปเจคไอเด็นติไฟเออร์ ที่เอ็มเอสส่งไปให้แต่จะเป็นข้อมูลของออปเจคไอเด็นติไฟเออร์ ของตัวถัดไปในโครงสร้าง เอสเอ็มไอ (SMI) ซึ่งจะใช้ในการที่ตัวเอ็มเอสไม่สามารถที่จะระบุออปเจคไอเด็นติไฟเออร์ได ้

xxii

1. SetRequest เป็นข้อความที่เอ็มเอสใช้บอกให้เอ็มเอเปลี่ยนแปลงการตั้งค่าต่างๆของข้อมูลในมิบ (MIB)

2. GetResponse เป็นข้อความที่เอ็มเอใช้ในการส่งผลลัพธ์กลับมาให้เอ็มเอสจากการที่ เอ็มเอสได้ทาการส่งข้อความ GetRequest, GetNextRequest, SetRequest ไปให้

3. Trap เป็นข้อความที่เอ็มเอส่งไปให้ เอ็มเอสเพ่ือรายงานเหตุการณ์หรือปัญหาที่เกิด ขึ้นจากเอ็มเอโดยที่ไม่ได้มีการร้องขอข้อมูลมาจากเอ็มเอสรูปแบบข้อความรายงานเหตุการณ์มี 7 ชนิด ดังต่อไปนี้

• Cold-start (0) อุปกรณ์รีสตาร์ทอย่างกะทันหันเนื่องจากเกิดข้อผิดพลาด

• Warm-start (1) อุปกรณ์รีสตาร์ทเนื่องมาจากชุดค าสั่งของคอมพิวเตอร์

• Link-down (2) การเชื่อมต่อไม่ส าเร็จ ล้มเหลวหรือเกิดข้อผิดพลาด

• Link-Up (3) การเชื่อมต่อกลับมาใช้งานได้ตามปกติหลังเกิดการท างานที่ผิดพลาด

• Failure-of-authentication (4) จากการตรวจสอบขัอมูลได้รับชื่อคอมมูนิตี้ไม่ถูกต้อง

• EGP-neighbor-loss (5) โปรโตคอลอีจีพี (EGP) ในอุปกรณ์ข้างเคียงดาวน์หรือดับไป

• Enterprise-specific (6) เป็นข้อความส าหรับผู้ผลิตอุปกรณ์นั้นเป็นผู้ก าหนดขึ้นมาใช้งานเอง

4. GetBulkRequest เป็นข้อความที่เอ็มเอส่งไปยังเอเจนต์เพ่ือใช้ดึงข้อมูลในจ านวนมากๆ

5. InformRequest เป็นข้อความที่เอ็มเอสตัวหนึ่งส่งข้อความไปยังเอ็มเอสอีกตัวหนึ่งที่อยู่ไกลออกไป เพ่ือรับค่าตัวแปรบางตัวจากเอ็มเอที่อยู่ภายใต้การควบคุมของเอ็มเอสที่ห่างอยู่ไกล

6. Report เป็นการออกแบบมาเพ่ือรายงานความผิดพลาดบางประเภทระหว่างเอ็มเอส ด้วยกัน

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

xxiii

SNMP Communities Limoncelli, Tom. [4] ได้กล่าวว่า SNMPv1 และ SNMPv2 ใช้ระบบคอมมิวนิตี้ในการสร้างความปลอดภัยในการรับส่งข้อมูลระหว่างเมเนเจอร์ และเอเจนต์ โดยทั่วไปเอเจนต์จะถูกตั้งค่าให้มีคอมมิวนิตี้ 3 ประเภท คือ อ่านได้อย่างเดียว สามารถอ่านเขียน และแทรป ชื่อคอมมิวนิตี้ หรือคอมมิวนิตี้สตริง อันที่จริงท างานเสมือนเป็นรหัสผ่าน โดยผู้ผลิตทั่วไปจะให้คอมมิวนิตี้สตริง ชื่อ Public ส าหรับการอ่านได้อย่างเดียว คอมมิวนิตี้สตริง ชื่อ Private ส าหรับการอ่านและเขียน ตามรูปที่ 2.6

รูปที่ 2.6 แสดง SNMP Community

Manager and Agent เมเนเจอร์ (Manager) คือเซิร์ฟเวอร์ที่รันซอฟต์แวร์ หรือโปรแกรมบริหารจัดการระบบ

เครือข่าย หรือที่ถูกเรียกว่า NMS (Network Management Stations) ท าหน้าที่ร้องขอ (Request บางครั้งเรียกว่า Query) หรือโพลลิ่ง (Polling) หรือรับข้อมูลประเภทแทรป (Trap) ที่ถูกส่งจากตัวเอเจนต์โดยไม่ได้ร้องขอ

การโพลล์ คือการร้องขอข้อมูลจากเอเจนต์ เช่น จากเราเตอร์ หรือสวิตช์ ข้อมูลเหล่านี้

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

เอเจนต์ โดยทั่วไปคือโปรแกรม หรือเฟิร์มแวร์ (Firmware) ที่ติดตั้ง และท างานบนตัว

อุปกรณ์เครือข่ายที่ผู้ดูแลระบบเครือข่ายต้องการจัดการ ซึ่งอาจจะเป็นโปรแกรมเฉพาะ และท างานเบื้องหลั งเป็นแบ็กกราวด์ โพรเซส (Background Process) หรือเดมอน (Daemon) เช่น ใน

xxiv

ไมโครซอฟต์วินโดว์ หรือยูนิกซ์ หรือเป็นส่วนหนึ่งในระบบปฏิบัติการ เช่น ในเราเตอร์ของ CISCO ซึ่งเป็นเฟิร์มแวร์ระดับต่ า

ในปัจจุบันอุปกรณ์ที่ใช้โปรโตคอล TCP/IP ส่วนใหญ่จะมาพร้อมกับตัวเอเจนต์ SNMP

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

รูปที่ 2.7 แสดงความสัมพันธ์ระหว่าง Manager and Agent

2.5 Management Information Base (MIB)

MIB ซึ่งเป็นโครงสร้างของข้อมูลเพ่ือการจัดการ (SMI: Structure of Management Information) ระบุถึงวิธีการนิยามออบเจ็กต์ (Object) และพฤติกรรมการท างาน (Behavior) MIB ซึ่งเป็นโครงสร้างของข้อมูลเพ่ือการจัดการ (SMI: Structure of Management Information) ระบุถึงวิธีการนิยามออบเจ็กต์ (Object) และพฤติกรรมการท างาน (Behavior) ของเอเจนต์ เพ่ือติดตามการท างานของอุปกรณ์ หนึ่งในรายการที่ส าคัญก็คือ Object ที่แสดงสถานะการท างานของพอร์ท เราเตอร์ (Up, Down หรือ Testing) รายการดังกล่าวจะเป็นข้อมูลที่ตัวเมเนเจอร์สามารถตรวจสอบสภาพการท างานของอุปกรณ์เครือข่ายได้

xxv

MIB เป็นฐานข้อมูล ที่เอเจนต์ใช้ตรวจสอบสภาพการท างานของอุปกรณ์ เช่น สถานะ ข้อมูลเชิงปริมาณและทางสถิติของอุปกรณ์เครือข่าย โดยรูปแบบโครงสร้างของออบเจ็กต์จะถูกนิยามตาม SMI ในหนึ่งเอเจนต์อาจมีหลาย MIB แต่ทุก ๆ เอเจนต์จะมี MIB ส่วนกลางเพียงตัวเดียวเรียกว่า MIB-II (RFC 1213) ตัว MIB-II เป็นฐานข้อมูลมาตรฐานที่นิยามตัวแปรมาตรฐานต่าง ๆ ที่ตัวอุปกรณ์เครือข่ายต้องมี เช่น ข้อมูลของพอร์ต (ความเร็ว จ านวนไบต์รับ จ านวนไบต์ส่ง เป็นต้น) รวมทั้งข้อมูลที่บรรยายถึงตัวอุปกรณ์เอง เช่น ต าแหน่งที่ตั้ง ชื่อผู้ดูแล เป็นต้น

xxvi

บทที่ 3 การออกแบบและวิธีด าเนินการ

3.1 กล่าวน า ในบทนี้ผู้ศึกษาจะได้อธิบายขั้นตอนการพัฒนาระบบเฝ้าระวังและตรวจสอบสถานะการ

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

3.2 ระบบที่น าเสนอ 3.2.1 ภาพรวมองค์ประกอบของระบบ การท างานและการออกแบบ

ระบบเฝ้าระวังและตรวจสอบสถานะการท างานของ Zimbra อีเมลเซิร์ฟเวอร์ จะท างานในลักษณะ Web Application ท าหน้าที่การตรวจสอบทรัพยากรระบบและสถานะเซอร์วิสของ Zimbraผ่านโปรโตคอล SNMP อยู่ตลอดเวลา โดยภาพรวมของระบบ แสดงดังรูปที่ 3.1

รูปที่ 3.1 ภาพรวมของระบบเฝ้าระวังและตรวจสอบสถานะการท างานของอีเมลเซิร์ฟเวอร์

xxvii

องค์ประกอบของระบบ ระบบเฝ้าระวังและตรวจสอบการท างานของอีเมลเซิร์ฟเวอร์ประกอบไปด้วยโปรแกรมย่อย 3 ส่วนคือ

1. โปรแกรม Monitoring ท าหน้าที่เฝ้าระวังและตรวจสอบสถานะการท างานของอีเมลเซิร์ฟเวอร์อยู่ตลอดเวลา โดยแบ่งการตรวจสอบออกเป็น 2 ส่วนคือ

1.1 ตรวจสอบขนาดการใช้งานทรัพยากรระบบ (Resource Monitoring) ได้แก่ CPU, RAM, Swap, Disk

1.2 ตรวจสอบการท างานของเซอร์วิสที่เป็นองค์ประกอบส าคัญของ Zimbra (Zimbra Service Monitoring) ประกอบไปด้วยเซอร์วิส amavis, ldap, mailbox, memcached, mta, proxy และ configd

2. โปรแกรมระบบแจ้งเตือนอัตโนมัติ (System Alert) ท าหน้าที่แจ้งเตือนผู้ดูแลระบบผ่านช่องทางอีเมลและโปรแกรมไลน์ของผู้ดูแลระบบ ทั้งนี้โปรแกรมจะแจ้งเตือนใน 2 กรณี คือ กรณีที่มีการใช้งานทรัพยากรระบบในข้อ 1.1 เกินค่าที่ก าหนดไว้ และ กรณีที่เซอร์วิสส าคัญของ Zimbra ในข้อ 1.2 หยุดท างาน

3. โปรแกรม Remote Command เป็นโปรแกรมที่ท าหน้าที่สั่ ง Restart Service ของ Zimbra ผ่านระบบเครือข่าย เมื่อโปรแกรม Monitoring ในข้อ 1 ตรวจสอบพบว่ามีเซอร์วิสของ Zimbra ในข้อ 1.2 หยุดท างาน โปรแกรม Remote Command จะท าการส่งค าสั่ง Restart Service ของ Zimbra ตัวที่หยุดท างานในทันที

การท างานของระบบ กลไกการท างานของระบบจะเริ่มจากการที่ระบบท าการส่ง command SNMPget ไปยัง

อีเมลเซิร์ฟเวอร์ปลายทาง เพ่ือรวบรวมข้อมูลที่ต้องการซึ่งมีท้ังหมด 2 ส่วน คือ 1. ข้อมูลการใช้งานทรัพยากรระบบ (CPU, Ram, Swap, Disk) หลังจากที่ได้ค่าข้อมูลการใช้

งานมา ระบบจะท าการค านวณหาเปอร์เซ็นต์การใช้งานทรัพยากร (เทียบกับ 100%) แล้วน าไปเปรียบเทียบกับเกณฑ์ที่ผู้ดูแลระบบได้ก าหนดเอาไว้ (Threshold) หากเกินกว่าค่าที่ก าหนดไว้ ระบบ System Alert จะท าการส่งข้อความแจ้งเตือนไปยังผู้ดูแลระบบ ทั้งนี้ผู้ดูแลระบบสามารถก าหนดเกณฑ์การประเมินสถานะของทรัพยากรระบบ (threshold) ได้ 3 ระดับ ดังนี้

• สถานะปกติ (Normal)

• สถานะเฝ้าระวัง (Warning)

• สถานะวิกฤติ (Critical) 2. ข้อมูลสถานะการท างานของเซอร์วิส หลังจากที่ได้ข้อมูลสถานะการท างานมา ระบบจะท า

การตรวจสอบว่าสถานะการท างานของเซอร์วิสแต่ละตัวอยู่ในสถานะ “running” หรือไม่ หากไม่อยู่ในสถานะ “running” (มีสถานะเป็น stopped) ระบบ System Alert จะท าการส่งข้อความแจ้ง

xxviii

เตือนไปยังผู้ดูแลระบบ พร้อมสั่งโปรแกรม Remote Command ให้ท าการส่งค าสั่งรีสตาร์ทเซอร์วิสที่มีปัญหาในทันที

3.3 ขั้นตอนในการพัฒนาระบบ 3.3.1 ท าการศึกษาข้อมูลภาพรวมและสภาพปัญหา 3.3.2 ศึกษาแนวคิดและทฤษฎีที่เกี่ยวข้อง เช่นแนวคิดด้านการบริหารจัดการเครือข่าย

โปรโตคอล SNMP การควบคุมสั่งการ Linux Server ผ่าน Remote Server 3.3.3 หาค่า OID ของ Zimbra และระบบปฏิบัติการ Ubuntu ที่เก่ียวข้องกับระบบ 3.3.4 น าข้อมูลที่ได้จากการศึกษามาออกแบบและพัฒนาระบบ 3.3.5 ท าการทดสอบการท างานของระบบและปรับปรุงแก้ไข 3.3.6 น าเสนอผลการพัฒนาระบบ วิเคราะห์ และสรุปผลการพัฒนาระบบพร้อม

ข้อเสนอแนะ

สภาพแวดล้อมของระบบท่ีท าการทดสอบ ผู้ศึกษาจะท าการทดสอบระบบที่ออกแบบบนเครื่องเซิร์ฟเวอร์จ าลองบนโครงสร้างพ้ืนฐาน VMware Esxi 5.5 โดยแบ่งออกเป็น 2 ส่วนดังนี้

ส่วนของ Zimbra Server 1. เซิร์ฟเวอร์เสมือน ขนาด CPU 2 vCPUs Ram 8GB Harddisk 300GB.

ติดตั้งระบบ Ubuntu 14.04.5 LTS 2. Zimbra Collaboration Server รุ่น Open Source Edition เวอร์ชั่น

Release 8.7.11.GA.1854.UBUNTU14.64 UBUNTU14_64 FOSS edition ส่วนของระบบเฝ้าระวังและตรวจสอบการท างานของอีเมลเซิร์ฟเวอร์

1. เซิร์ฟเวอร์เสมือน ขนาด CPU 2 vCPUs Ram 8GB Harddisk 300GB. ติดตั้งระบบ Ubuntu 14.04.5 LTS

2. Apache Web Server เวอร์ชั่น 2.4.17 ติดตั้ง PHP เวอร์ชั่น 5.6.12 ฐานข้อมูล MySQL เวอร์ชั่น 5.6.12

xxix

3.4 Flowchart การท างานของระบบ ระบบเฝ้าระวังและตรวจสอบสถานะการท างานของอีเมลเซิร์ฟเวอร์ สามารถแสดงผังการ

ท างาน ได้ดังนี้

Flowchart แสดงการท างานในภาพรวมของระบบ

รูปที่ 3.2 แสดงแผนภาพการท างานของระบบแจ้งเตือนอัตโนมัติ

กลไกการท างานของระบบประกอบไปด้วยโปรแกรมย่อย 3 ตัวคือ โปรแกรมตรวจสอบสถานะการท างานของระบบอีเมลเซิร์ฟเวอร์ โปรแกรมแจ้งเตือนผู้ดูแลระบบและโปรแกรม Remote Command ทั้งนี้สามารถแสดงผังการท างานของแต่ละโปรแกรมได้ดังนี้

xxx

Flowchart แสดงการท างานของระบบตรวจสอบสถานะการท างาน (Monitoring)

รูปที่ 3.3 แสดงแผนภาพการท างานของโปรแกรมแจ้งเตือนอัตโนมัติ

กลไกการท างานของโปรแกรมจะเริ่มจากการที่ระบบตรวจสอบและเฝ้าระวังตรวจสอบจะส่ง

ค าสั่ง SNMPget ไปที่อีเมลเซิร์ฟเวอร์ปลายทาง หากส าเร็จก็จะท าการน าค่าข้อมูลที่ได้ไปบันทึกค่าในฐานข้อมูลพร้อมทั้งแสดงค่าสถานะการท างานบนหน้าการจัดการ

xxxi

Flowchart แสดงการท างานของโปรแกรมแจ้งเตือนอัตโนมัติ (Alert)

รูปที่ 3.4 แสดงแผนภาพการท างานของโปรแกรมแจ้งเตือนอัตโนมัติ กลไกการท างานของโปรแกรมจะเริ่มจากการที่ระบบตรวจสอบและเฝ้าระวังตรวจสอบพบว่า

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

xxxii

Flowchart แสดงการท างานของระบบ Remote Command

รูปที่ 3.5 แสดงแผนภาพการท างานของโปรแกรม Remote Command

กลไกการท างานของโปรแกรมจะเริ่มจากการที่ระบบตรวจสอบและเฝ้าระวังตรวจสอบพบว่ามีเซอร์วิสของ Zimbra บนอีเมลเซิร์ฟเวอร์ปลายทางหยุดท างานหรือไม่ หากพบว่ามีเซอร์วิสของ Zimbra ตัวใดหยุดท างาน โปรแกรม Remote Command จะท าการส่งค าสั่ง Restart Service ไปยังเครื่องอีเมลเซิร์ฟเวอร์ที่พบปัญหาในทันที

xxxiii

การออกแบบฐานข้อมูล

รูปที่ 3.6 แสดงแผนภาพแสดงความสัมพันธ์ระหว่างข้อมูล DPata Dictionary

ตารางที่ 3.1 tbl_server เก็บข้อมูลเซิร์ฟเวอร์

ชื่อฟิลด์ ชนิดข้อมูล รายละเอียดข้อมูล หมายเหตุ

server_id Int(11) รหัสเซิร์ฟเวอร์ PK ip_address Varchar(100) หมายเลขไอพี

snmp_community Varchar(100) ชื่อคอมมิวนิตี้ key_ssh text ค่า Public Key

interval_time Int(11) ช่วงเวลาในการดึงข้อมูล

server_status Int(11) สถานะเซิร์ฟเวอร์

xxxiv

ตารางที่ 3.2 tbl_ram_usage เก็บข้อมูลหน่วยความจ า

ชื่อฟิลด์ ชนิดข้อมูล รายละเอียดข้อมูล หมายเหตุ seq_code Varchar(100) หมายเลขล าดับ PK

server_id Int(11) รหัสเซิร์ฟเวอร์ FK

date_time datetime วันที่และเวลา PK total decimal(50,0) หน่วยความจ าทั้งหมด

available decimal(50,0) หน่วยความจ าที่ใช้ได้ buffered decimal(50,0) หน่วยความจ าส ารอง

cached decimal(50,0) หน่วยความจ าชั่วคราว

ตารางที่ 3.3 tbl_cpu1_usage เก็บข้อมูล Load Average ของเซิร์ฟเวอร์

ชื่อฟิลด์ ชนิดข้อมูล รายละเอียดข้อมูล หมายเหตุ seq_code varchar(100) หมายเลขล าดับ PK

server_id Int(11) รหัสเซิร์ฟเวอร์ FK

date_time datetime วันที่และเวลา PK usage_value float ค่าโหลดของระบบ

ตารางที่ 3.4 tbl_swap_usage เก็บข้อมูลหน่วยความจ าชั่วคราว (ดิสก์)

ชื่อฟิลด์ ชนิดข้อมูล รายละเอียดข้อมูล หมายเหตุ

seq_code varchar(100) หมายเลขล าดับ PK server_id Int(11) รหัสเซิร์ฟเวอร์ FK

date_time datetime วันที่และเวลา PK

ชื่อฟิลด์ ชนิดข้อมูล รายละเอียดข้อมูล หมายเหตุ total decimal(50,0) หน่วยความจ าทั้งหมด

available decimal(50,0) หน่วยความจ าที่ใช้ได้

ตารางที่ 3.5 tbl_disk_usage เก็บข้อมูลหน่วยความจ า

ชื่อฟิลด์ ชนิดข้อมูล รายละเอียดข้อมูล หมายเหตุ seq_code varchar(100) หมายเลขล าดับ PK

server_id Int(11) รหัสเซิร์ฟเวอร์ FK date_time datetime วันที่และเวลา PK

usage_value float เปอร์เซ็นต์การใช้งาน

xxxv

ตารางที่ 3.6 tbl_zimbra_status เก็บข้อมูลสถานะของเซอร์วิส Zimbra

ชื่อฟิลด์ ชนิดข้อมูล รายละเอียดข้อมูล หมายเหตุ seq_code varchar(100) หมายเลขล าดับ PK

server_id Int(11) รหัสเเซิร์ฟเวอร์ FK

date_time datetime วันที่และเวลา PK amavis varchar(100) สถานะของ amavis

ldap varchar(100) สถานะของ ldap memcache varchar(100) สถานะของ memcache

mailboxd varchar(100) สถานะของ mailboxd

mta varchar(100) สถานะของ mta proxy varchar(100) สถานะของ proxy

ชื่อฟิลด์ ชนิดข้อมูล รายละเอียดข้อมูล หมายเหตุ

configd varchar(100) สถานะของ configd

ตารางที่ 3.7 tbl_severity_zimbra เก็บข้อมูลเกณฑ์การประเมินสถานะของเซอร์วิส Zimbra ชื่อฟิลด์ ชนิดข้อมูล รายละเอียดข้อมูล หมายเหตุ

severity_name varchar(1) ชื่อเกณฑ์การประเมิน PK

level_info Int(11) ค่าระดับเกณฑ์ปกติ level_critical Int(11) ค่าระดับเกณฑ์วิกฤติ

send_trigger varchar(1) สถานะการส่งค าสั่ง send_email varchar(1) สถานะการส่งอีเมลเตือน

send_line varchar(1) สถานะการส่งข้อความไลน์

ตารางที่ 3.8 tbl_severity_zimbra เก็บข้อมูลเกณฑ์การประเมินสถานะของทรัพยากรระบบ

ชื่อฟิลด์ ชนิดข้อมูล รายละเอียดข้อมูล หมายเหตุ severity_name varchar(100) ชื่อเกณฑ์การประเมิน PK

level_info Int(11) ค่าระดับเกณฑ์ปกติ

level_warning Int(11) ค่าระดับเกณฑ์วิกฤติ level_critical Int(11) ค่าระดับเกณฑ์วิกฤติ

send_email varchar(1) สถานะการส่งอีเมลเตือน

send_line varchar(1) สถานะการส่งข้อความไลน์

xxxvi

ตารางที่ 3.9 tbl_login เก็บข้อมูลบัญชีผู้ใช้งาน

ชื่อฟิลด์ ชนิดข้อมูล รายละเอียดข้อมูล หมายเหตุ login_id Int(11) รหัสผู้ใช้งาน PK

username varchar(100) ชื่อผู้ใช้งาน PK

password varchar(100) รหัสผ่าน firstname varchar(100) ชื่อพนักงาน

lastname varchar(100) นามสุกล email varchar(100) ที่อยู่บัญชีอีเมล

login_type varchar(100) ประเภทบัญชี

login_status Int(1) สถานะการเข้าสู่ระบบ

ตารางที่ 3.10 tbl_policy เก็บข้อมูลเงื่อนไขการเข้าใช้งาน ชื่อฟิลด์ ชนิดข้อมูล รายละเอียดข้อมูล หมายเหตุ

login_id Int(11) รหัสผู้ใช้งาน PK

sub_menu_id Int(11) รหัสเมนูย่อย PK policy_add varchar(1) สถานะการเพ่ิมข้อมูล

policy_edit varchar(1) สถานะการแก้ไขข้อมูล

policy_delete varchar(1) สถานะการลบข้อมูล

ตารางที่ 3.11 tbl_main_menu เก็บข้อมูลเมนูหลัก ชื่อฟิลด์ ชนิดข้อมูล รายละเอียดข้อมูล หมายเหตุ

menu_id Int(11) รหัสเมนูหลัก PK

main_menu_var varchar(100) รายละเอียดเมนู main_menu_name varchar(100) ชื่อเมนูหลัก

fa_icon varchar(100) ข้อมูลไอคอน main_menu_seq Int(11) ล าดับเมนู

xxxvii

ตารางที่ 3.12 tbl_sub_menu เก็บข้อมูลเมนูหลัก

ชื่อฟิลด์ ชนิดข้อมูล รายละเอียดข้อมูล หมายเหตุ sub_menu_id Int(11) รหัสเมนูย่อย PK

menu_id Int(11) รหัสเมนูหลัก FK

sub_menu_name varchar(100) ชื่อเมนูย่อย page_file varchar(100) ชื่อไฟล์ .php

sub_menu_seq Int(11) ล าดับเมนู

3.5 ต้นแบบโครงร่าง (Prototype Design) หน้า Login เข้าสู่ระบบ

รูปที่ 3.7 แสดงหน้า Login เข้าสู่ระบบ หน้า Dashboard

รูปที่ 3.8 แสดงหน้า Dashboard

xxxviii

หน้า Monitor Resource

รูปที่ 3.9 แสดงหน้า Monitor Resource

xxxix

บทที่ 4 ผลการทดลอง

4.1 กล่าวน า

จากการศึกษาหลักการต่างๆ องค์ความรู้ และทฤษฎีที่เกี่ยวข้อง เพ่ือพัฒนาระบบเฝ้าระวังและตรวจสอบสถานะการท างานของอีเมลเซิร์ฟเวอร์ และได้ท าการออกแบบระบบ รวมทั้งน าไปทดสอบฟังก์ชั่นการใช้งานในด้านต่างๆ ผลการทดลองโดยรวมพบว่าสามารถน าไปใช้ได้ตามวัตถุประสงค์ที่ก าหนดไว้ และผู้ศึกษาคาดว่าผู้ประกอบการจะสามารถน าไปใช้ในการป้องกันปัญหา และเพ่ิมประสิทธิภาพการท างานได้ต่อไป

4.2 เคร่ืองมือที่ใช้ในการทดลองและสภาพแวดล้อม สภาพแวดล้อมของระบบท่ีท าการทดสอบ ผู้ศึกษาได้ท าการทดสอบระบบที่ออกแบบบนเครื่องเซิร์ฟเวอร์จ าลองบนโครงสร้างพ้ืนฐาน VMware Esxi 5.5 โดยแบ่งออกเป็น 2 ส่วนดังนี้

ส่วนของ Zimbra Server 1. เซิร์ฟเวอร์เสมือน ขนาด CPU 2 vCPUs Ram 8GB Harddisk 300GB.

ติดตั้งระบบ Ubuntu 14.04.5 LTS 2. Zimbra Collaboration Server รุ่น Open Source Edition เวอร์ชั่น

Release 8.7.11.GA.1854.UBUNTU14.64 UBUNTU14_64 FOSS edition ส่วนของระบบเฝ้าระวังและตรวจสอบการท างานของอีเมลเซิร์ฟเวอร์

1. เซิร์ฟเวอร์เสมือน ขนาด CPU 2 vCPUs Ram 8GB Harddisk 300GB. ติดตั้งระบบ Ubuntu 14.04.5 LTS

2. Apache Web Server เวอร์ชั่น 2.4.17 ติดตั้ง PHP เวอร์ชั่น 5.6.12 ฐานข้อมูล MySQL เวอร์ชั่น 5.6.12

4.3 ขั้นตอนการท างานและการทดสอบระบบ ผู้ศึกษาได้แบ่งส่วนการทดสอบระบบเฝ้าระวังและตรวจสอบสถานะการท างานของอีเมล

เซิร์ฟเวอร์ ออกเป็น 4 ส่วนดังนี้ 1. การทดสอบก าหนดข้อมูลระบบ 2. การทดสอบตรวจสอบสถานะทรัพยากรระบบและสถานะเซอร์วิสของ Zimbra 3. การทดสอบระบบแจ้งเตือน 4. การทดสอบสั่งรีสตาร์ทเซอร์วิสจากระบบ

xl

4.4 การทดสอบก าหนดขอ้มูลระบบ 4.4.1 การเข้าสู่ระบบ ท าการเรียกใช้งานโปรแกรมระบบเฝ้าระวังและตรวจสอบสถานะการท างานของอีเมล

เซิร์ฟเวอร์ จะปรากฏหน้าจอตรวจสอบสิทธิ์และยืนยันตัวตนก่อนเข้าใช้งานระบบ พิมพ์ชื่อผู้ใช้งานและรหัสผ่านแล้วคลิก Login เพ่ือเข้าสู่ระบบ ดังรูปที่ 4.1

รูปที่ 4.1 รูปหน้าจอการเข้าใช้งานระบบ

เมื่อเข้าสู่ระบบส าเร็จจะปรากฏหน้าจอแสดงข้อความและเครื่องหมายถูก ดังรูปที่ 4.2

รูปที่ 4.2 รูปแสดงผลการเข้าสู่ระบบส าเร็จ

xli

จากนั้นโปรแกรมจะแสดงหน้าจอหลักของระบบ หรือ Dashboard ดังรูปที่ 4.3

รูปที่ 4.3 รูปหน้าจอหลักของระบบ (Dashboard) 4.4.2 การก าหนดข้อมูลระบบ

การก าหนดข้อมูลระบบแบ่งเป็น 2 ส่วนคือ ส่วนของการจัดการเซิร์ฟเวอร์และบัญชีผู้ใช้งาน กับส่วนของการก าหนดเกณฑ์ (threshold) หรือระดับของความรุนแรงของความผิดปกติของทรัพยากรระบบและเซอร์วิสของ Zimbra ที่ต้องการตรวจสอบและเฝ้าระวัง

การจัดการข้อมูลเครื่องเซิร์ฟเวอร์

ทดสอบโดยการเพิ่มเครื่อง Zimbra Server ใหม่ โดยเข้าไปที่เมนู Setting เลือกเมนู Server Management จากนั้นเลือกค าสั่ง Add เพ่ือเพ่ิม Zimbra Server ที่ต้องการมอนิเตอร์ จะปรากฏหน้าต่างให้ป้อนข้อมูล หมายเลขไอพี ค่า SNMP Community ค่ากุญแจสาธารณะ (Public Key) ส าหรับ SSH และระบุช่วงเวลาที่ต้องการให้ระบบท าการดึงค่าข้อมูล SNMP ในแต่ละรอบ ดังรูปที่ 4.4

xlii

รูปที่ 4.4 แสดงข้อมูลการเพิ่มเซิร์ฟเวอร์ใหม่ เมื่อท าการเพ่ิมและบันทึกข้อมูลเรียบร้อยแล้ว รายการ Zimbra Server ใหม่จะปรากฏอยู่ในหน้าต่าง Server Management ดังรูปที่ 4.5

รูปที่ 4.5 แสดงรายชื่อของ Zimbra เซิร์ฟเวอร์ ที่อยู่ในระบบ ผลการทดสอบ

หลังจากท าการเพ่ิมข้อมูล Zimbra เซิร์ฟเวอร์ใหม่เข้าไปในระบบแล้ว ท าการตรวจสอบโดยเข้าไปที่ เมนู Dashboard จะปรากฏรายการเซิร์ฟเวอร์ใหม่เพ่ิมขึ้นมาบนหน้าจอการท างานหลัก (Dashboard) พร้อมกับแสดงสถานะของทรัพยากรระบบและสถานะการท างานของเซอร์วิสของ Zimbra ดังรูปที่ 4.6

xliii

รูปที่ 4.6 รูปหน้าจอหลักของระบบ (Dashboard)

ท าการคลิกไปที่หมายเลขไอพี 27.254.139.57 จะปรากฏรายละเอียดเพ่ิมเติมดังรูปที่ 4.7

รูปที่ 4.7 รูปแสดงหน้าจอรายละเอียดสถานะของ Zimbra เซิร์ฟเวอร์ การจัดการบัญชีผู้ใช้งานระบบ

ทดสอบโดยการเพิ่มบัญชีผู้ใช้งานใหม่ ให้เลือกที่เมนู Setting เลือกเมนู User Management จากนั้นเลือกค าสั่ง Add แล้วท าการเพ่ิมข้อมูลของผู้ใช้งานใหม่ที่ต้องการให้เข้าใช้งานระบบ ดังรูปที่ 4.8

xliv

รูปที่ 4.8 แสดงหน้าจอเพ่ิมข้อมูลบัญชีผู้ใช้งานใหม่

ก าหนดสิทธิ์ในการเข้าใช้งาน โดยปลดสิทธิ์การลบรายการเซิร์ฟเวอร์ และปลดสิทธิ์ในการเพิ่มบัญชีผู้ใช้งาน จากนั้นท าการบันทึกค่า ดังรูปที่ 4.9

รูปที่ 4.9 แสดงหน้าจอการก าหนดสิทธิ์การเข้าใช้งานของบัญชีผู้ใช้งาน ผลการทดสอบ

xlv

หลังจากท าการเพ่ิมข้อมูล บัญชีผู้ใช้งานใหม่ เข้าไปในระบบแล้ว ท าการทดสอบโดยเข้าสู่ระบบด้วยชื่อบัญชีใหม่ ผลการทดสอบพบว่า สามารถเข้าสู่ระบบได้ส าเร็จ ดังรูปที่ 4.10 และ 4.11

รูปที่ 4.10 แสดงหน้าจอการเข้าสู่ระบบของบัญชีผู้ใช้งานใหม่

รูปที่ 4.11 แสดงผลการเข้าสู่ระบบของผู้ใช้งานใหม่ส าเร็จ

การก าหนดเกณฑ์ (Threshold) การตรวจสอบ ทดสอบโดยการปรับเกณฑ์ (Threshold) หรือระดับของความรุนแรงของความผิดปกติของ

ทรัพยากรระบบ โดยเลือกปรับเกณฑ์ระดับเฝ้าระวัง (Warning) ของหน่วยความจ า (Memory) โดยเข้าไปที่เมนู Severity Level จากนั้นเลือกไปที่เมนู Resource และปรับเงื่อนไขจากเดิมค่า >50% ให้เป็นค่าใหม่ >30% แล้วตรวจสอบผลจากเมนูแสดงสถานะ

เกณฑ์ระดับเฝ้าระวัง (Warning) ของ Memory ก่อนท าการทดสอบปรับค่า (>50%)

xlvi

รูปที่ 4.12 แสดงผลเกณฑ์การตรวจสอบทรัพยากรระบบก่อนปรับค่า

ท าการตรวจสอบสถานะของการใช้งาน Memory โดยไปที่เมนู Dashboard ปรากฏสถานะดังรูป ที่ 4.13 และ 4.14

รูปที่ 4.13 แสดงสถานะของการใช้งาน Memory ก่อนทดสอบ

xlvii

รูปที่ 4.14 แสดงสถานะรายละเอียดของการใช้งาน Memory ก่อนทดสอบ

ท าการปรับเงื่อนไขเกณฑ์ระดับเฝ้าระวัง (Warning) ของหน่วยความจ า (Memory) จากเดิมค่า >50% ให้เป็นค่าใหม่ >30% ปรากฏสถานะดังรูป ที่ 4.15

รูปที่ 4.15 แสดงผลเกณฑ์การตรวจสอบทรัพยากรระบบหลังปรับค่าเพ่ือทดสอบ ผลการทดสอบ

หลังท าการปรับเงื่อนไขเกณฑ์ระดับเฝ้าระวัง (Warning) ของหน่วยความจ า (Memory) ท าการตรวจสอบสถานะของการใช้งาน Memory โดยไปท่ีเมนู Dashboard กฎสถานะดังรูปที่ 4.16 และ 4.17

xlviii

รูปที่ 4.16 แสดงสถานะของการใช้งาน Memory หลังทดสอบ

รูปที่ 4.17 แสดงสถานะและรายละเอียดของการใช้งาน Memory หลังทดสอบ

4.4.2 การทดสอบตรวจสอบสถานะทรัพยากรระบบและสถานะเซอร์วิสของ Zimbra ทดสอบโดยท าการตรวจสอบผลลัพธ์ที่ได้จากการใช้ค าสั่ง command line บนเครื่อง

Zimbra เซิร์ฟเวอร์ เปรียบเทียบกับ ผลลัพธ์ที่แสดงบนโปรแกรมที่พัฒนา ปรากฏในรูปที่ 4.18 – 14.21

รูปที่ 4.18 แสดงผลการตรวจสอบ Disk บนเครื่อง Zimbra เซิร์ฟเวอร์

xlix

รูปที่ 4.19 แสดงผลการตรวจสอบ Disk บนโปรแกรม

รูปที่ 4.20 แสดงผลการตรวจสอบสถานะเซอร์วิส amavis บนเครื่อง Zimbra เซิร์ฟเวอร์

รูปที่ 4.21 แสดงผลการตรวจสอบสถานะเซอร์วิส amavis บนโปรแกรม

ผลการทดสอบ ผลการตรวจสอบได้ผลลัพธ์ตรงกัน 4.4.3 การทดสอบระบบแจ้งเตือน

1. การทดสอบตรวจสอบสถานะทรัพยากรระบบและสถานะเซอร์วิสของ Zimbra 2. การทดสอบระบบแจ้งเตือน

การทดสอบสั่งรีสตาร์ทเซอร์วิสจากระบบท าทดสอบใน 2 สถานะการ ดังนี้ 1. สถานะการที่มีการใช้ทรัพยากรระบบเกินกว่าเกณฑ์ระดับเฝ้าระวัง (Warning) โดยท าการ

ปรับลดเกณฑ์ระดับเฝ้าระวัง (Warning) ของหน่วยความจ า (Memory) จากค่า >50% ให้เป็น >30% เมื่อตรวจสอบสถานะบนระบบพบว่า การใช้หน่วยความจ าของ Zimbra เซิร์ฟเวอร์อยู่ในเกณฑ์ระดับเฝ้าระวัง ดังปรากฏในรูปที่ 4.22

l

รูปที่ 4.22 แสดงผลการตรวจสอบ Disk บนโปรแกรม

ผลการทดสอบ

รูปที่ 4.23 ข้อความอีเมลแจ้งเตือนจากระบบ

รูปที่ 4.24 ข้อความจากระบบ Line Notify

li

2. สถานะการที่มีการตรวจพบเซอร์วิสของ Zimbra หยุดท างาน (Stopped) ดังปรากฏในรูปที่ 4.25

รูปที่ 4.25 แสดงผลการตรวจสอบพบเซอร์วิส Amavis หยุดท างาน ผลการทดสอบ

รูปที่ 4.26 ข้อความอีเมลแจ้งเตือนจากระบบ

รูปที่ 4.27 ข้อความจากระบบ Line Notify

lii

4.4.4 การทดสอบสั่งรีสตาร์ทเซอร์วิสจากระบบ ทดสอบโดย Stop เซอร์วิส amavis บนเครื่อง Zimbra เซิร์ฟเวอร์ เมื่อระบบตรวจ

พบว่าเซอร์วิส amavis บนเครื่อง Zimbra เซิร์ฟเวอร์หยุดท างาน ระบบได้ท าการแจ้งเตือนพร้อมกับส่งค าสั่ง restart service amavis บนเครื่อง Zimbra เซิร์ฟเวอร์ ดังปรากฏในรูปที่ 4.28 และ 4.29

รูปที่ 4.28 แสดงผลการตรวจสอบพบเซอร์วิส amavis หยุดท างาน ผลการทดสอบ เมื่อตรวจสอบข้อมูล Log บนเครื่อง Zimbra เซิร์ฟเวอร์ พบว่าเซอร์วิส amavis ถูก restart service และกลับมาเป็นสถานะท างานเป็นปกติ (changed from stopped to running) ดังปรากฏในรูปที่ 4.29

รูปที่ 4.29 แสดงผลการปรับสถานะของ amavis สรุปผลการทดสอบ จากการทดสอบระบบเฝ้าระวังและตรวจสอบสถานะการท างานของอีเมลเซิร์ฟเวอร์ ทั้ง 4 ส่วนพบว่าสามารถท างานได้ตามวัตถุประสงค์

liii

บทที่ 5 สรุปผลการด าเนินงาน

5.1 ผลการด าเนินงานโครงงาน ผลการน าระบบเฝ้าระวังและตรวจสอบสถานการณ์ท างานของอีเมลเซิร์ฟเวอร์ไปทดลอง ใช้งานบนฟังก์ชั่นด้านต่างๆ พบว่าระบบที่พัฒนามีคุณลักษณะดังนี้

5.1.1 มีความสามารถในการเฝ้าระวังแบบรวมศูนย์ 5.1.2 ไม่ต้องติดตั้งซอร์ฟแวร์บนฝั่งอีเมลเซิร์ฟเวอร์ (Agent Less) 5.1.3 มีความยืดหยุ่นสูง ใช้งานง่าย ผู้ดูแลระบบสามารถบริหารจัดการได้เองทั้งระบบ 5.1.4 สามารถตรวจสอบและแสดงสถานะการใช้ทรัพยากรระบบได้ 5.1.5 สามารถตรวจสอบและแสดงสถานะการท างานของเซอร์วิสบนอีเมลเซิร์ฟเวอร์ได้ 5.1.6 สามารถส่งค าสั่ง Restart Service ไปยังอีเมลเซิร์ฟเวอร์ปลายทางได้ เมื่อพบว่ามี

เซอร์วิสหยุดท างาน 5.1.7 สามารถส่งการแจ้งเตือนผ่านช่องทางอีเมลและแอพพลิเคชั่นไลน์ ไปยังผู้ดูแลระบบได้

เมื่อพบว่ามีการใช้ทรัพยากรเกินเกณฑ์ท่ีก าหนด หรือ กรณีท่ีมีเซอร์วิสหยุดท างาน 5.1.8 ผลที่ได้รับเป็นไปตามวัตถุประสงค์ที่ผู้ศึกษาคาดไว้ ดังนั้นหากผู้ให้บริการอีเมล

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

5.2 ปัญหาและอุปสรรค 5.2.1 การท างานของระบบเป็นแบบ Web Application หากเกิดปัญหาขึ้นกับ Web Server จะท าให้ระบบไม่สามารถใช้งานได้ 5.2.2 อีเมล Zimbra เวอร์ชั่นโอเพ่นซอส มีข้อจ ากัดในการพัฒนาระบบครั้งนี้ กล่าวคือ ไม่มี ฟังก์ชั่นที่สนับสนุนการท างานบนโปรโตคอล SNMP 5.3 ข้อเสนอแนะและแนวทางในการพัฒนาในอนาคต 5.3.1 ควรมีการเพ่ิมฟังก์ชั่นในการตรวจสอบการท างานในด้านอื่นๆ เช่น จ านวนอีเมลในคิว ปริมาณการรับส่งอีเมล เป็นต้น 5.3.2 ควรมีการเพ่ิมรายละเอียดอื่นๆ อาทิเช่น รายละเอียดเครื่องเซิร์ฟเวอร์ Hostname และจ านวน cpu เป็นต้น

liv

เอกสารอ้างอิง

[1] บริษัท เซิร์ฟเวอร์ทูเดย์ (ประเทศไทย) จ ากัด, สิงหาคม 2560, สัมภาษณ์ [2] Charles Kozierok, The TCP/IP guide : a comprehensive, illustrated internet protocols reference. San Francisco:William Pollock, 2005 [3] Forouzan Behrouz A., TCP/IP protocol suite. New York:McGraw-Hill, 2010

[4] Limoncelli, Tom., Thomas A., Christina J., Hogan, Strata R. and Chalup., The practice of system and network

administration. Boston:Pearson Education, Inc, 2012

[5] Synacor, Inc., Zimbra Collaboration Administrator Guide. New York:Synacor, 2016 [6] Cisco Systems. Network management basics.[Online]. Available: http://docwiki.cisco.com/wiki/Network_Management_Basics