National Environmental Satellite Data Information Service (NESDIS) ได้ลดต้นทุนการจัดการการกำหนดค่าสำหรับ Red Hat Enterprise Linux (RHEL) ลง 35% โดยการย้ายจาก Puppet Enterprise ไปยัง Ansible Tower ในวิดีโอ "วิธีที่เราทำ" นี้ Michael Rau วิศวกรระบบจะอธิบายกรณีของการย้ายครั้งนี้ แบ่งปันเคล็ดลับที่เป็นประโยชน์และบทเรียนที่ได้รับจากการย้ายจาก SCM หนึ่งไปยังอีก SCM
จากวิดีโอนี้คุณจะได้เรียนรู้:
- วิธีพิสูจน์ความเหมาะสมในการจัดการความเป็นไปได้ในการเปลี่ยนจาก Puppet Enterprise เป็น Ansible Tower
- กลยุทธ์ใดที่จะใช้เพื่อทำให้การเปลี่ยนแปลงราบรื่นที่สุดเท่าที่จะเป็นไปได้
- เคล็ดลับสำหรับการแปลงรหัส PE ที่แสดงเป็น Ansible Playbook
- คำแนะนำสำหรับการติดตั้ง Ansible Tower ให้เหมาะสมที่สุด
สวัสดีทุกคน ฉันชื่อ Michael Rau เป็นวิศวกรระบบอาวุโสที่ ActioNet ซึ่งทำงานให้กับบริการ NESDIS ของ National Oceanic and Atmospheric Administration (NOAA) วันนี้เราจะพูดถึงการตัดสาย - ประสบการณ์ของฉันในการย้ายจาก Puppet Enterprise ไปยัง Ansible Tower ธีมของการนำเสนอนี้คือ “ดูรอยแผลเป็นของฉัน” ที่เหลือหลังจากที่ฉันทำการเปลี่ยนแปลงนี้เมื่อต้นปี ฉันต้องการแบ่งปันสิ่งที่ฉันเรียนรู้จากกระบวนการนี้ ดังนั้นเมื่อคุณทำอะไรแบบนี้โดยใช้ประสบการณ์ของฉัน คุณสามารถเปลี่ยนแปลงได้โดยไม่ต้องทำงานพิเศษใดๆ
คุณจะเห็นสไลด์ที่คล้ายกันนี้ที่จุดเริ่มต้นของทุกการนำเสนอที่ Ansible Fest สไลด์นี้สรุปประวัติความเป็นมาของระบบอัตโนมัติของบริษัทของฉัน ฉันไม่ใช่คนใหม่ในเรื่องนี้เพราะฉันใช้ Puppet/Puppet Enterprise มาตั้งแต่ปี 2007 ฉันเริ่มทำงานกับ Ansible ในปี 2016 และเช่นเดียวกับผู้ใช้ผลิตภัณฑ์นี้รายอื่น ๆ ฉันได้รับความสนใจจากความเป็นไปได้ของ "เทคนิค" โดยใช้บรรทัดคำสั่งและสคริปต์ง่ายๆ (คู่มือการเล่น) เมื่อปลายปี 2017 ฉันได้ติดต่อฝ่ายบริหารเกี่ยวกับเหตุผลสำคัญในการย้ายมาที่ Ansible Tower อีกสักครู่ฉันจะบอกคุณเกี่ยวกับเหตุผลที่ทำให้ฉันต้องทำตามขั้นตอนนี้ หลังจากได้รับความยินยอมจากฝ่ายบริหารแล้ว ก็ต้องใช้เวลาหลายเดือนกว่าจะเสร็จสิ้นแผน และฉันได้ดำเนินการเปลี่ยนแปลงในเดือนมกราคมถึงกุมภาพันธ์ของปีนี้ ดังนั้นเราจึงละทิ้ง Puppet โดยสิ้นเชิงเพื่อสนับสนุน Ansible และมันเป็นสิ่งที่ดีมาก
สิ่งที่ดึงดูดฉันมากที่สุดเกี่ยวกับ Ansible คือความสามารถในการเขียนและใช้บทบาทและ playbooks บทบาทเหมาะสำหรับการสร้างงานที่แตกต่างกันแต่มีความเกี่ยวข้อง และรวมข้อมูลทั้งหมดที่เกี่ยวข้องกับงานเหล่านั้นไว้ในที่เดียว Playbook คือไฟล์สคริปต์ไวยากรณ์ YAML ที่อธิบายการดำเนินการสำหรับโฮสต์ตั้งแต่ XNUMX รายการขึ้นไป ฉันแจ้งให้ผู้ใช้ทราบเกี่ยวกับคุณสมบัติเหล่านี้ โดยเฉพาะนักพัฒนาซอฟต์แวร์ Ansible Tower ช่วยให้คุณสามารถพูดว่า “ไม่ คุณไม่มีสิทธิ์เข้าถึงเชลล์ แต่ฉันให้ความสามารถในการรันกระบวนการ Tower ทั้งหมดและเริ่มบริการใหม่เมื่อคุณต้องการ” ฉันจะบอกคุณเกี่ยวกับสภาพแวดล้อมการทำงานและอุปกรณ์ที่เราใช้
นี่คือ LAN ของรัฐบาลกลาง, ไซต์ทางกายภาพ 7 แห่งที่เชื่อมต่อผ่านคลาวด์ MPLS, เซิร์ฟเวอร์ 140 RHEL, 99% ซึ่งเป็นเซิร์ฟเวอร์เสมือน (vSphere), ฮาร์ดแวร์ SuperMicro, ที่เก็บข้อมูลเครือข่าย NexentaStore, ชุดสวิตช์ Cisco, Arista และ Cumulus และการจัดการภัยคุกคามแบบรวมศูนย์ Fortinet UTM เครื่องมือในแต่ละไซต์
เครือข่ายของรัฐบาลกลางหมายความว่าฉันต้องใช้มาตรการรักษาความปลอดภัยข้อมูลทั้งหมดที่กฎหมายกำหนด คุณควรจำไว้ว่า Puppet Enterprise ไม่รองรับฮาร์ดแวร์ส่วนใหญ่ที่เราใช้ เราถูกบังคับให้ใช้ฮาร์ดแวร์งบประมาณเนื่องจากหน่วยงานของรัฐมีปัญหาในการจัดหาเงินทุนสำหรับรายการค่าใช้จ่ายนี้ นั่นเป็นเหตุผลที่เราซื้อฮาร์ดแวร์ SuperMicro และประกอบอุปกรณ์ของเราจากชิ้นส่วนแต่ละชิ้น ซึ่งรับประกันการบำรุงรักษาตามสัญญาของรัฐบาล เราใช้ Linux และนี่คือหนึ่งในเหตุผลสำคัญในการเปลี่ยนมาใช้ Ansible
ประวัติของเรากับหุ่นเชิดมีดังนี้
ในปี 2007 เรามีเครือข่ายขนาดเล็กจำนวน 20-25 โหนด ซึ่งเราได้ปรับใช้ Puppet โดยพื้นฐานแล้วโหนดเหล่านี้เป็นเพียง "กล่อง" ของ RedHat ในปี 2010 เราเริ่มใช้เว็บอินเทอร์เฟซ Puppet Dashboard สำหรับ 45 โหนด ในขณะที่เครือข่ายขยายตัวอย่างต่อเนื่อง เราได้ย้ายไปยัง PE 2014 ในปี 3.3 ทำให้เกิดการเปลี่ยนแปลงอย่างสมบูรณ์ด้วยการเขียนรายการใหม่สำหรับโหนด 75 รายการ ต้องทำสิ่งนี้เพราะ Puppet ชอบเปลี่ยนกฎของเกม และในกรณีนี้ พวกเขาเปลี่ยนภาษาโดยสิ้นเชิง อีกหนึ่งปีต่อมา เมื่อการรองรับ Puppet Enterprise เวอร์ชัน 3 สิ้นสุดลง เราถูกบังคับให้ย้ายข้อมูลไปยัง PE 2015.2 เราต้องเขียนรายการอีกครั้งอีกครั้งสำหรับเซิร์ฟเวอร์ใหม่และซื้อใบอนุญาตโดยสำรอง 100 โหนด แม้ว่าในเวลานั้นเราจะมีเพียง 85 โหนดเท่านั้น
เวลาผ่านไปเพียง 2 ปี และเราก็ต้องทำงานหนักอีกครั้งเพื่อโยกย้ายไปยัง PE เวอร์ชันใหม่ 2016.4 เราซื้อใบอนุญาตสำหรับ 300 โหนดโดยมีเพียง 130 โหนด เราต้องทำการเปลี่ยนแปลงครั้งใหญ่กับรายการอีกครั้งเนื่องจากเวอร์ชันใหม่ของภาษามีไวยากรณ์ที่แตกต่างจากภาษาของเวอร์ชันปี 2015 ด้วยเหตุนี้ SCM ของเราจึงเปลี่ยนจากการควบคุมเวอร์ชัน SVN เป็น Bitbucket (Git) นี่คือ "ความสัมพันธ์" ของเรากับหุ่นเชิด
ดังนั้นฉันจึงต้องอธิบายให้ฝ่ายบริหารทราบว่าเหตุใดเราจึงต้องย้ายไปยัง SCM อื่นโดยใช้ข้อโต้แย้งต่อไปนี้ ประการแรกคือราคาบริการที่สูง ฉันได้พูดคุยกับทีมงานที่ RedHat และพวกเขาบอกว่าค่าใช้จ่ายในการใช้งานเครือข่าย 300 โหนดด้วย Ansible Tower นั้นเป็นค่าใช้จ่ายครึ่งหนึ่งของ Puppet Enterprise หากคุณซื้อ Ansible Engine ด้วย ราคาจะพอๆ กัน แต่คุณจะได้รับฟีเจอร์ต่างๆ มากกว่า PE เนื่องจากเราเป็นบริษัทของรัฐที่ได้รับทุนจากงบประมาณของรัฐบาลกลาง นี่จึงเป็นข้อโต้แย้งที่ทรงพลังทีเดียว
อาร์กิวเมนต์ที่สองคือความเก่งกาจ Puppet รองรับเฉพาะฮาร์ดแวร์ที่มีตัวแทน Puppet ซึ่งหมายความว่าต้องติดตั้งเอเจนต์บนสวิตช์ทั้งหมด และต้องเป็นเวอร์ชันล่าสุด และหากสวิตช์บางตัวของคุณรองรับเวอร์ชันหนึ่ง และบางตัวรองรับอีกเวอร์ชันหนึ่ง คุณจะต้องติดตั้ง PE agent เวอร์ชันใหม่บนสวิตช์เหล่านั้น เพื่อให้สวิตช์ทั้งหมดสามารถทำงานได้ในระบบ SCM เดียวกัน
ระบบ Ansible Tower ทำงานแตกต่างออกไปเนื่องจากไม่มีตัวแทน แต่มีโมดูลที่รองรับสวิตช์ของ Cisco และสวิตช์อื่นๆ ทั้งหมด SCM นี้รองรับ Qubes OS, Linux และ 4.NET UTM Ansible Tower ยังรองรับตัวควบคุมการจัดเก็บข้อมูลเครือข่าย NexentaStore ที่ใช้เคอร์เนล Illumos ซึ่งเป็นระบบปฏิบัติการ Unix แบบโอเพ่นซอร์ส นี่เป็นการสนับสนุนเพียงเล็กน้อย แต่ Ansible Tower ก็ทำเช่นนั้นอยู่ดี
ข้อโต้แย้งข้อที่สามซึ่งสำคัญมากทั้งสำหรับฉันและฝ่ายบริหารของเราคือใช้งานง่าย ฉันใช้เวลา 10 ปีในการเรียนรู้โมดูล Puppet และรหัสรายการ แต่ฉันเรียนรู้ Ansible ภายในหนึ่งสัปดาห์เพราะ SCM นี้ทำงานง่ายกว่ามาก แน่นอนว่าหากคุณเรียกใช้ไฟล์ปฏิบัติการ เว้นแต่คุณจะทำเช่นนั้นโดยไม่จำเป็น ตัวจัดการที่ชาญฉลาดและตอบสนองจะทำงานร่วมกับไฟล์เหล่านั้นได้ Playbook ที่ใช้ YAML นั้นเรียนรู้ได้ง่ายและใช้งานได้รวดเร็ว ผู้ที่ไม่เคยได้ยินเกี่ยวกับ YAML มาก่อนสามารถอ่านสคริปต์และเข้าใจวิธีการทำงานได้อย่างง่ายดาย
พูดตามตรง Puppet ทำให้งานของคุณในฐานะนักพัฒนายากขึ้นมากเพราะมันมีพื้นฐานมาจากการใช้ Puppet Master เป็นเครื่องเดียวที่ได้รับอนุญาตให้สื่อสารกับตัวแทนหุ่นเชิด หากคุณได้ทำการเปลี่ยนแปลงใดๆ กับไฟล์ Manifest และต้องการทดสอบโค้ดของคุณ คุณต้องเขียนโค้ดใหม่สำหรับ Puppet Master กล่าวคือ กำหนดค่าไฟล์ Puppet Master /etc/hosts เพื่อเชื่อมต่อไคลเอ็นต์ทั้งหมดและเริ่มบริการ Puppet Server หลังจากนี้คุณจะสามารถทดสอบการทำงานของอุปกรณ์เครือข่ายบนโฮสต์เดียวได้ นี่เป็นขั้นตอนที่ค่อนข้างเจ็บปวด
ทุกอย่างง่ายกว่ามากใน Ansible สิ่งที่คุณต้องทำคือพัฒนาโค้ดสำหรับเครื่องที่สามารถสื่อสารผ่าน SSH กับโฮสต์ที่อยู่ระหว่างการทดสอบ มันง่ายกว่ามากในการทำงานด้วย
ข้อได้เปรียบที่สำคัญถัดไปของ Ansible Tower คือความสามารถในการใช้ประโยชน์จากระบบสนับสนุนที่มีอยู่ของคุณและรักษาการกำหนดค่าฮาร์ดแวร์ที่มีอยู่ SCM นี้ใช้ข้อมูลที่มีอยู่ทั้งหมดเกี่ยวกับโครงสร้างพื้นฐานและฮาร์ดแวร์ เครื่องเสมือน เซิร์ฟเวอร์ ฯลฯ โดยไม่มีขั้นตอนเพิ่มเติม มันสามารถพูดคุยกับเซิร์ฟเวอร์ RH Satellite ของคุณได้ หากคุณมี และให้การผสานรวมที่คุณจะไม่มีวันได้รับจาก Puppet
สิ่งสำคัญอีกประการหนึ่งคือการควบคุมอย่างละเอียด คุณทราบดีว่า Puppet เป็นระบบโมดูลาร์ ซึ่งเป็นแอปพลิเคชันไคลเอ็นต์-เซิร์ฟเวอร์ ดังนั้นคุณต้องกำหนดลักษณะต่างๆ ที่มีอยู่ของเครื่องทั้งหมดของคุณไว้ในไฟล์ Manifest แบบยาวรายการเดียว ในกรณีนี้ จะต้องทดสอบสถานะของแต่ละองค์ประกอบของระบบทุกครึ่งชั่วโมง ซึ่งเป็นช่วงเวลาเริ่มต้น นี่คือวิธีการทำงานของหุ่นเชิด
ทาวเวอร์ช่วยคุณจากสิ่งนั้น คุณสามารถรันกระบวนการต่างๆ บนอุปกรณ์ต่างๆ ได้โดยไม่มีข้อจำกัด คุณสามารถทำงานพื้นฐาน รันกระบวนการสำคัญอื่นๆ ตั้งค่าระบบรักษาความปลอดภัย และทำงานกับฐานข้อมูลได้ คุณสามารถทำทุกอย่างที่ยากได้ใน Puppet Enterprise ดังนั้น หากคุณกำหนดค่าไว้บนโฮสต์เดียว จะต้องใช้เวลาก่อนที่การเปลี่ยนแปลงจะมีผลกับโฮสต์ที่เหลือ ใน Ansible การเปลี่ยนแปลงทั้งหมดจะมีผลพร้อมกัน
สุดท้ายเรามาดูโมดูลความปลอดภัยกัน Ansible Tower ใช้งานได้อย่างน่าอัศจรรย์ โดยมีความแม่นยำและการดูแลเอาใจใส่เป็นเลิศ คุณสามารถให้สิทธิ์ผู้ใช้เข้าถึงบริการเฉพาะหรือโฮสต์เฉพาะได้ ฉันทำเช่นนี้กับพนักงานที่เคยชินกับการทำงานบน Windows โดยจำกัดการเข้าถึงเชลล์ Linux ฉันแน่ใจว่าพวกเขาสามารถเข้าถึง Tower เพื่อที่พวกเขาจะได้ทำงานและให้บริการเฉพาะที่เกี่ยวข้องกับพวกเขาเท่านั้น
มาดูสิ่งที่คุณต้องทำล่วงหน้าเพื่อให้การเปลี่ยนไปใช้ Ansible Tower ง่ายขึ้น ก่อนอื่นคุณต้องเตรียมอุปกรณ์ของคุณก่อน หากองค์ประกอบบางอย่างของโครงสร้างพื้นฐานของคุณไม่ได้อยู่ในฐานข้อมูล คุณจะต้องเพิ่มองค์ประกอบเหล่านั้นที่นั่น มีระบบที่ไม่เปลี่ยนคุณลักษณะดังนั้นจึงไม่อยู่ในฐานข้อมูล Puppet แต่ถ้าคุณไม่เพิ่มเข้าไปก่อนที่จะย้ายไปที่ Tower คุณจะสูญเสียข้อได้เปรียบหลายประการ นี่อาจเป็นฐานข้อมูลเบื้องต้นที่ "สกปรก" แต่ควรมีข้อมูลเกี่ยวกับอุปกรณ์ทั้งหมดที่คุณมี ดังนั้นคุณควรเขียนสคริปต์ฮาร์ดแวร์แบบไดนามิกที่จะผลักดันการเปลี่ยนแปลงโครงสร้างพื้นฐานทั้งหมดไปยังฐานข้อมูลโดยอัตโนมัติ จากนั้น Ansible จะรู้ว่าโฮสต์ใดควรมีอยู่ในระบบใหม่ คุณไม่จำเป็นต้องบอก SCM นี้ว่าโฮสต์ใดที่คุณเพิ่มและโฮสต์ใดไม่มีอยู่อีกต่อไป เพราะมันจะรู้ทั้งหมดนี้โดยอัตโนมัติ ยิ่งมีข้อมูลในฐานข้อมูลมากขึ้น Ansible ก็จะมีประโยชน์และยืดหยุ่นมากขึ้นเท่านั้น ทำงานเหมือนกับเพียงอ่านบาร์โค้ดสถานะฮาร์ดแวร์จากฐานข้อมูล
ใช้เวลาทำความคุ้นเคยกับบรรทัดคำสั่งใน Ansible เรียกใช้คำสั่งที่กำหนดเองเพื่อทดสอบสคริปต์ฮาร์ดแวร์ เขียนและเรียกใช้สคริปต์ Playbook ที่เรียบง่ายแต่มีประโยชน์ ใช้เทมเพลต Jinja2 ตามความเหมาะสม ลองเขียนบทบาทและสคริปต์สำหรับกระบวนการที่ซับซ้อนหลายขั้นตอนโดยใช้การกำหนดค่าฮาร์ดแวร์ทั่วไปที่พบโดยทั่วไป เล่นกับสิ่งเหล่านี้ ทดสอบว่ามันทำงานอย่างไร ด้วยวิธีนี้คุณจะได้เรียนรู้วิธีใช้เครื่องมือสร้างห้องสมุดที่ใช้ใน Tower ฉันได้กล่าวไปแล้วว่าฉันใช้เวลาประมาณ 3 เดือนในการเตรียมตัวสำหรับการเปลี่ยนแปลง ฉันคิดว่าจากประสบการณ์ของฉัน คุณจะสามารถทำได้เร็วขึ้น อย่าคิดว่าการเสียเวลานี้สูญเปล่า เพราะในภายหลังคุณจะพบกับประโยชน์ทั้งหมดของงานที่ทำเสร็จแล้ว
ถัดไป คุณต้องตัดสินใจว่าคุณคาดหวังอะไรจาก Ansible Tower ว่าระบบนี้ควรทำอะไรให้คุณบ้าง
คุณจำเป็นต้องปรับใช้ระบบบนฮาร์ดแวร์เปล่า หรือบนเครื่องเสมือนเปล่าหรือไม่? หรือคุณต้องการรักษาสภาพการทำงานและการตั้งค่าเดิมของอุปกรณ์ที่มีอยู่? นี่เป็นสิ่งสำคัญมากสำหรับบริษัทมหาชน ดังนั้นคุณต้องแน่ใจว่าคุณจะสามารถย้ายและปรับใช้ Ansible บนการกำหนดค่าที่มีอยู่ของคุณได้ ระบุกระบวนการดูแลระบบตามปกติที่คุณต้องการทำให้เป็นแบบอัตโนมัติ ค้นหาว่าคุณจำเป็นต้องปรับใช้แอปพลิเคชันและบริการเฉพาะบนระบบใหม่หรือไม่ เขียนรายการสิ่งที่คุณต้องการทำและจัดลำดับความสำคัญ
จากนั้นเริ่มเขียนโค้ดสคริปต์และบทบาทที่จะช่วยให้งานที่คุณวางแผนจะทำให้สำเร็จได้ รวมไว้ใน Projects ซึ่งเป็นคอลเลกชันเชิงตรรกะของ Playbooks ที่เกี่ยวข้อง แต่ละโปรเจ็กต์จะอยู่ในพื้นที่เก็บข้อมูล Git ที่แยกจากกันหรือพื้นที่เก็บข้อมูลที่แตกต่างกัน ขึ้นอยู่กับตัวจัดการรหัสที่คุณใช้ คุณสามารถจัดการสคริปต์ Playbook และไดเร็กทอรี Playbook ได้โดยการวางสคริปต์เหล่านั้นใน Project Base Path บนเซิร์ฟเวอร์ Tower ด้วยตนเอง หรือโดยการวาง Playbook ในระบบการจัดการซอร์สโค้ด (SCM) ที่รองรับโดย Tower รวมถึง Git, Subversion, Mercurial และ Red Hat ข้อมูลเชิงลึก ภายในโปรเจ็กต์เดียว คุณสามารถวางสคริปต์ได้มากเท่าที่คุณต้องการ ตัวอย่างเช่น ฉันสร้างโปรเจ็กต์พื้นฐานหนึ่งโปรเจ็กต์ที่ฉันวางสคริปต์สำหรับองค์ประกอบหลัก RedHat สคริปต์สำหรับคอร์ Linux และสคริปต์สำหรับส่วนที่เหลือของบรรทัดฐาน ดังนั้นในโปรเจ็กต์หนึ่งจึงมีบทบาทและสถานการณ์ที่หลากหลายที่ได้รับการจัดการจากที่เก็บ Git เดียว
การเรียกใช้สิ่งเหล่านี้ทั้งหมดผ่านทางบรรทัดคำสั่งเป็นวิธีที่ดีในการทดสอบฟังก์ชันการทำงาน นี่จะเตรียมคุณให้พร้อมสำหรับการติดตั้ง Tower
มาพูดคุยกันเล็กน้อยเกี่ยวกับการแปลงรหัสรายการ Puppet เพราะฉันใช้เวลากับสิ่งนี้มากจนกระทั่งรู้ว่าต้องทำอะไรจริงๆ
อย่างที่ผมบอกไปก่อนหน้านี้ Puppet เก็บการตั้งค่าและตัวเลือกฮาร์ดแวร์ทั้งหมดไว้ใน Manifest แบบยาวรายการเดียว และ Manifest นี้เก็บทุกอย่างที่ SCM นี้ควรทำ เมื่อทำการเปลี่ยนแปลง คุณไม่จำเป็นต้องอัดงานทั้งหมดของคุณลงในรายการเดียว แต่ให้คิดถึงโครงสร้างของระบบใหม่แทน: บทบาท สคริปต์ แท็ก กลุ่ม และสิ่งที่ควรอยู่ตรงนั้น องค์ประกอบเครือข่ายอัตโนมัติบางส่วนควรจัดกลุ่มเป็นกลุ่มที่สามารถสร้างสคริปต์ได้ องค์ประกอบโครงสร้างพื้นฐานที่ซับซ้อนมากขึ้นซึ่งเกี่ยวข้องกับทรัพยากรจำนวนมาก รวมถึงคลาสที่มีในตัวเอง สามารถนำมารวมกันเป็นบทบาทได้ ก่อนที่จะย้ายคุณต้องตัดสินใจเรื่องนี้ หากคุณกำลังสร้างบทบาทหรือสถานการณ์ขนาดใหญ่ที่ไม่พอดีกับหน้าจอเดียว คุณควรใช้แท็กเพื่อให้สามารถจับภาพบางส่วนของโครงสร้างพื้นฐานได้
18:00
โฆษณาบางส่วน🙂
ขอบคุณที่อยู่กับเรา คุณชอบบทความของเราหรือไม่? ต้องการดูเนื้อหาที่น่าสนใจเพิ่มเติมหรือไม่ สนับสนุนเราโดยการสั่งซื้อหรือแนะนำให้เพื่อน , อะนาล็อกที่ไม่เหมือนใครของเซิร์ฟเวอร์ระดับเริ่มต้นซึ่งเราคิดค้นขึ้นเพื่อคุณ: (ใช้ได้กับ RAID1 และ RAID10 สูงสุด 24 คอร์ และสูงสุด 40GB DDR4)
Dell R730xd ถูกกว่า 2 เท่าในศูนย์ข้อมูล Equinix Tier IV ในอัมสเตอร์ดัม? ที่นี่ที่เดียวเท่านั้น ในเนเธอร์แลนด์! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - จาก $99! อ่านเกี่ยวกับ
ที่มา: will.com