ประโยชน์ของ EBS กับอินสแตนซ์สโตร์ (และในทางกลับกัน) [ปิด]

ฉันไม่ชัดเจนว่าฉันได้รับประโยชน์อะไรจาก EBS กับร้านค้าอินสแตนซ์สำหรับอินสแตนซ์ของฉันใน Amazon EC2 หากมีสิ่งใดดูเหมือนว่า EBS นั้นมีประโยชน์มากกว่า (หยุดเริ่มคงอยู่ + ความเร็วที่ดีขึ้น) ในราคาที่ต่างกันเล็กน้อย ... ? นอกจากนี้ยังมีการวัดว่าผู้คนจำนวนมากกำลังใช้ EBS อยู่หรือไม่ในขณะนี้เนื่องจากมีอยู่ว่ายังค่อนข้างใหม่อยู่หรือไม่

บรรทัดล่างคือคุณควรใช้อินสแตนซ์ที่ได้รับการสนับสนุนของ EBS เกือบตลอดเวลา

นี่คือเหตุผล

• สามารถตั้งค่าอินสแตนซ์ที่ได้รับการสนับสนุน EBS เพื่อให้ไม่สามารถยกเลิก (โดยไม่ตั้งใจ) ผ่าน API
• อินสแตนซ์ที่ได้รับการสนับสนุนของ EBS สามารถหยุดทำงานได้เมื่อคุณไม่ได้ใช้งานและกลับมาทำงานต่อเมื่อคุณต้องการอีกครั้ง (เช่นหยุดพีซีเสมือน) อย่างน้อยกับรูปแบบการใช้งานของฉัน
• อินสแตนซ์ที่ได้รับการสนับสนุนของ EBS จะไม่สูญเสียพื้นที่จัดเก็บอินสแตนซ์เมื่อเกิดข้อผิดพลาด (ไม่ใช่ข้อกำหนดสำหรับผู้ใช้ทั้งหมด แต่ทำให้การกู้คืนเร็วขึ้นมาก)
• คุณสามารถปรับขนาดการจัดเก็บอินสแตนซ์ EBS แบบไดนามิก
• คุณสามารถถ่ายโอนที่เก็บข้อมูลอินสแตนซ์ EBS ไปเป็นอินสแตนซ์ใหม่ได้ (มีประโยชน์หากฮาร์ดแวร์ที่ Amazon ที่คุณใช้งานอยู่ได้รับความไม่สม่ำเสมอหรือตายซึ่งเกิดขึ้นเป็นครั้งคราว)
• มันจะเร็วกว่าที่จะเรียกใช้อินสแตนซ์ที่ได้รับการสนับสนุนของ EBS เนื่องจากรูปภาพไม่จำเป็นต้องดึงข้อมูลจาก S3
• หากฮาร์ดแวร์อินสแตนซ์ที่ได้รับการสนับสนุน EBS ของคุณถูกกำหนดเวลาไว้สำหรับการบำรุงรักษาการหยุดและการเริ่มต้นอินสแตนซ์จะถูกย้ายไปยังฮาร์ดแวร์ใหม่โดยอัตโนมัติ ฉันยังสามารถย้ายอินสแตนซ์ที่สำรองข้อมูล EBS บนฮาร์ดแวร์ที่ล้มเหลวโดยบังคับให้หยุดอินสแตนซ์และเปิดใช้งานอีกครั้ง (ระยะของคุณอาจแตกต่างกันไปตามฮาร์ดแวร์ที่ล้มเหลว)

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

EBS ยังคงล้มเหลวไม่ใช่กระสุนเงิน

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

เมื่อไม่ถึง

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

การตั้งค่า AWS ของเรา 99% สามารถนำไปรีไซเคิลได้ ดังนั้นสำหรับฉันมันไม่สำคัญว่าถ้าฉันยกเลิกอินสแตนซ์ - ไม่มีอะไรหายไป เช่นแอปพลิเคชันของฉันถูกปรับใช้โดยอัตโนมัติในอินสแตนซ์จาก SVN บันทึกของเราจะถูกเขียนไปยังเซิร์ฟเวอร์กลาง syslog

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

[2012-07-16] วันนี้ฉันจะตอบคำถามนี้ต่างออกไปมาก

ฉันไม่เคยมีประสบการณ์ที่ดีกับอินสแตนซ์ที่ได้รับการสนับสนุน EBS ในปีที่ผ่านมาหรือมากกว่านั้น การหยุดทำงานครั้งสุดท้ายของ AWS ก็ทำให้ EBS ได้รับความเสียหายเช่นกัน

ฉันเดาว่าบริการอย่าง RDS จะใช้ EBS บางประเภทเช่นกันและดูเหมือนว่าจะทำงานได้เป็นส่วนใหญ่ ในกรณีที่เราจัดการเองเราได้กำจัด EBS ออกไปถ้าเป็นไปได้

กำจัดการขยายที่เราย้ายคลัสเตอร์ฐานข้อมูลกลับไปเป็น iron (= ฮาร์ดแวร์จริง) สิ่งเดียวที่เหลืออยู่ในโครงสร้างพื้นฐานของเราคือเซิร์ฟเวอร์ฐานข้อมูลซึ่งเรารวบรวม EBS หลายวอลุ่มไว้ในซอฟต์แวร์ RAID และสำรองข้อมูลสองครั้งต่อวัน อะไรก็ตามที่จะสูญหายระหว่างการสำรองข้อมูลเราสามารถอยู่กับ

EBS เป็นเทคโนโลยีที่ค่อนข้างสั่นเนื่องจากเป็นปริมาณเครือข่าย: ปริมาณที่เชื่อมต่อกับเซิร์ฟเวอร์ของคุณจากระยะไกล ฉันไม่ได้คัดค้านงานที่ทำไปแล้ว - มันเป็นผลิตภัณฑ์ที่น่าทึ่งเนื่องจากที่เก็บข้อมูลถาวรไม่ จำกัดเป็นเพียงแค่การเรียก API แต่มันก็ไม่ค่อยเหมาะสำหรับสถานการณ์ที่ประสิทธิภาพของ I / O เป็นกุญแจสำคัญ

และนอกจากวิธีการทำงานของที่เก็บข้อมูลเครือข่ายเครือข่ายทั้งหมดจะถูกแชร์ในอินสแตนซ์ EC2 อินสแตนซ์ที่มีขนาดเล็กกว่า (เช่น t1.micro, m1.small) ยิ่งแย่ลงเพราะเครือข่ายอินเทอร์เฟซของคุณบนระบบโฮสต์ที่ใช้ร่วมกันระหว่าง VMs หลายตัว (= อินสแตนซ์ EC2 ของคุณ) ซึ่งทำงานอยู่ด้านบน

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

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

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

เราชอบอินสแตนซ์สโตร์ มันบังคับให้เราทำอินสแตนซ์ของเราให้สามารถรีไซเคิลได้อย่างสมบูรณ์และเราสามารถทำให้กระบวนการสร้างเซิร์ฟเวอร์โดยอัตโนมัติจากศูนย์บน AMI ที่กำหนด นอกจากนี้ยังหมายความว่าเราสามารถแลกเปลี่ยน AMIs ได้อย่างง่ายดาย นอกจากนี้ EBS ยังมีปัญหาด้านประสิทธิภาพเป็นครั้งคราว

เอริคถูกจับมันมาก We ( Bitnami ) เป็นผู้ให้บริการ AMIs ยอดนิยมสำหรับแอพพลิเคชั่นยอดนิยมและกรอบการพัฒนา (PHP, Joomla, Drupal คุณได้รับแนวคิด) ฉันสามารถบอกคุณได้ว่า Amis ที่สนับสนุน EBS นั้นได้รับความนิยมมากกว่า S3 ที่ได้รับการสนับสนุนอย่างมาก โดยทั่วไปฉันคิดว่าอินสแตนซ์ s3 ที่สำรองไว้นั้นถูกใช้เพื่อการกระจายงานที่ จำกัด เวลา (ตัวอย่างเช่นการประมวลผลข้อมูลจำนวนมาก) ซึ่งหากเครื่องหนึ่งล้มเหลวอีกเครื่องหนึ่งจะถูกขัดขึ้น AMIS ที่ได้รับการสนับสนุน EBS มีแนวโน้มที่จะใช้สำหรับงานเซิร์ฟเวอร์ 'ดั้งเดิม' เช่นเว็บหรือเซิร์ฟเวอร์ฐานข้อมูลที่เก็บสถานะไว้ในเครื่องและต้องการข้อมูลที่จะพร้อมใช้งานในกรณีที่ระบบล่ม

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

ฉันมีประสบการณ์เช่นเดียวกับ Eric ในตำแหน่งสุดท้ายของฉัน ตอนนี้ในงานใหม่ของฉันฉันจะดำเนินการตามขั้นตอนเดียวกับที่ฉันทำในงานล่าสุดของฉัน ... การสร้าง AMI ใหม่ทั้งหมดสำหรับ EBS ที่ได้รับการสนับสนุน - และอาจเป็นเครื่องจักร 32 บิต (ราคาถูกกว่า - แต่ไม่สามารถใช้ AMI เดียวกันใน 32 และ 64 เครื่อง)

อินสแตนซ์ที่ได้รับการสนับสนุนของ EBS เปิดตัวเร็วพอที่คุณจะสามารถใช้ประโยชน์จากAmazon AutoScaling APIซึ่งช่วยให้คุณใช้ตัวชี้วัด CloudWatch เพื่อเปิดใช้งานอินสแตนซ์เพิ่มเติมและลงทะเบียนกับ ELB (Elastic Load Balancer) และปิดเมื่อ ไม่ต้องการอีกต่อไป

การแปลงสัญญาณอัตโนมัติแบบไดนามิกเช่นนี้เป็นสิ่งที่ AWS ให้ความสำคัญ - ซึ่งการประหยัดที่แท้จริงในโครงสร้างพื้นฐานด้านไอทีสามารถเกิดขึ้นได้ มันเป็นไปไม่ได้เลยทีเดียวที่จะทำการปรับค่าอัตโนมัติด้วยอินสแตนซ์ที่ได้รับการสนับสนุนของ s3 "InstanceStore" แบบเก่า

ฉันเพิ่งเริ่มใช้ EC2 ด้วยตัวเองไม่ใช่ผู้เชี่ยวชาญ แต่เอกสารของ Amazonบอกว่า:

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

เน้นการขุด

ฉันทำการวิเคราะห์ข้อมูลมากกว่าเว็บโฮสติ้งดังนั้นการคงอยู่จึงไม่สำคัญสำหรับฉันเท่าที่ควรสำหรับเว็บไซต์ จากความแตกต่างของ Amazon เองฉันไม่คิดเลยว่า EBS จะเหมาะกับทุกคน

ฉันจะพยายามจำน้ำหนักอีกครั้งหลังจากฉันใช้ทั้งคู่

EBS เปรียบเสมือนดิสก์เสมือนของ VM:

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

ที่เก็บข้อมูลอินสแตนซ์คือ:

• ในพื้นที่โดยทั่วไปจึงเร็วกว่า
• ไม่ใช่เครือข่ายในกรณีปกติ EBS I / O มาที่ค่าใช้จ่ายของแบนด์วิดท์เครือข่าย (ยกเว้นอินสแตนซ์ที่ปรับให้เหมาะสมกับ EBS ซึ่งมีแบนด์วิดท์ EBS แยกต่างหาก)
• มี I / O จำกัด ต่อวินาที IOPS แม้กระทั่ง I / O ที่ได้รับการจัดสรรสูงสุดไม่กี่พัน IOPS
• บอบบาง. ทันทีที่อินสแตนซ์หยุดคุณจะสูญเสียทุกอย่างในที่เก็บอินสแตนซ์

นี่คือที่ที่จะใช้แต่ละ:

• ใช้ EBS สำหรับพาร์ติชันระบบปฏิบัติการสำรองและที่เก็บข้อมูลถาวร (ข้อมูลฐานข้อมูล, บันทึกที่สำคัญ, แอปพลิเคชันที่กำหนดค่า)
• ใช้ที่เก็บอินสแตนซ์สำหรับข้อมูลในกระบวนการบันทึกที่ไม่สำคัญและสถานะแอปพลิเคชันชั่วคราว ตัวอย่าง: ที่เก็บข้อมูลภายนอก, tempfiles, ฯลฯ
• ที่เก็บอินสแตนซ์ยังสามารถใช้สำหรับข้อมูลที่มีประสิทธิภาพที่สำคัญเมื่อมีการจำลองแบบระหว่างอินสแตนซ์ (NoSQL DBs ระบบคิว / ข้อความแบบกระจายและฐานข้อมูลที่มีการจำลองแบบ)
• ใช้ S3 สำหรับข้อมูลที่ใช้ร่วมกันระหว่างระบบ: ชุดข้อมูลอินพุตและผลลัพธ์ที่ประมวลผลหรือสำหรับข้อมูลคงที่ที่ใช้โดยแต่ละระบบเมื่อ lauched
• ใช้ AMIs สำหรับเซิร์ฟเวอร์ที่เปิดตัวล่วงหน้าและเปิดใช้งาน

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

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

สำหรับใครที่ยังใหม่กับเรื่องทั้งหมดนี้และถ้าบังเอิญลงจอดที่นี่

ณ ตอนนี้ AMI ทั้งหมดในหมวด quickstart ได้รับการสนับสนุนจาก EBS

นอกจากนี้ยังมีคำอธิบายที่ดีที่doc อย่างเป็นทางการสำหรับความแตกต่างระหว่างEBSและร้านค้าตัวอย่าง

& ภาพนี้ผลรวมมันค่อนข้างมาก

ถ้าคุณเรียกใช้อินสแตนซ์หลายและกำหนดบริการที่กำหนดของ AWS อินสแตนซ์เป็นหนึ่งในความสำคัญของคุณในการหลีกเลี่ยงค่าใช้จ่ายที่ไม่คาดคิดฉันอยากจะแนะนำไม่ให้ใช้อินสแตนซ์ร้าน

ตามที่อธิบายไว้ในเอกสารของEBS เล่ม และคำตอบจากj2d3และSiddharth Sharmaอินสแตนซ์สโตร์สามารถทำงานได้นานเท่าที่คุณต้องการ แต่ไม่สามารถหยุดได้ หมายความว่าบริการไม่สามารถกำหนดได้โดยอัตโนมัติ START / STOPหรือตัวอย่างการกู้คืน

นอกจากนี้สำหรับรูปแบบประเภทนี้ยังไม่มีประโยชน์ในการใช้EBS BackedบนElastic Beanstalkเนื่องจากถูกออกแบบมาเพื่อให้แน่ใจว่าทรัพยากรทั้งหมดที่คุณต้องการยังคงทำงานต่อไป มันจะทำการเปิดใช้บริการใด ๆ ที่คุณหยุดทำงานอีกครั้งโดยอัตโนมัติ การตรวจสอบส่วนที่เหลือทั้งหมดออกจากค่าใช้จ่ายทั้งหมดในการใช้VPC , EBSและELBที่เพิ่มเข้ามาในEC2 คลาสสิกที่EC2-VPCกับELBส่วนใหญ่จะเป็นทางเลือกที่ดีที่สุดที่แตกต่างจากในEC2 คลาสสิกอินสแตนซ์หยุดยังคงเกี่ยวข้องยืดหยุ่น ที่อยู่ IPและปริมาณ EBS จะถูกเก็บไว้โดยอัตโนมัติ

โดยสรุปให้นำส่วนหลักของคำถามของคุณ:

ดูเหมือนว่า EBS นั้นมีประโยชน์มากกว่า (หยุด, เริ่มต้น, คงอยู่ + ความเร็วที่ดีขึ้น) ด้วยราคาที่ต่างกันเล็กน้อย ... ?

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

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

อย่างไรก็ตามหากมีสถานการณ์สมมติให้เรียกใช้แอปพลิเคชันด้วยบริการที่มีต้นทุนต่ำกว่าให้ดึงงานที่ไม่ได้จัดการทั้งหมดและมีบทบาทกับVPC / EBSผ่านไปป์ไลน์หรือแลมบ์ดาภายในระยะเวลาสั้น ๆ ว่า <1 ชั่วโมงต่อวันซึ่งเป็นไปไม่ได้ ใช้อินสแตนซ์สโตร์จากนั้นจะเป็นเรื่องราวที่แตกต่าง