คำถามติดแท็ก heartbeat

มีทางเลือกอื่นที่สำคัญสำหรับการ failover อัตโนมัติบน Linux นอกเหนือจาก Heartbeat / Pacemaker / CoroSync โดยเฉพาะอย่างยิ่งฉันกำลังตั้งค่า failover บนอินสแตนซ์ของ EC2 ซึ่งรองรับ unicast เท่านั้น - ไม่มีมัลติคาสต์หรือการออกอากาศ ฉันพยายามจัดการกับซอฟต์แวร์บางส่วนที่เรายังไม่มีซึ่งล้มเหลวโดยอัตโนมัติและไม่สนับสนุนสภาพแวดล้อมแบบหลายต้นแบบ ซึ่งรวมถึงเครื่องมือต่าง ๆ เช่น HAProxy และ Solr ฉันมี Heartbeat + Pacemaker ทำงาน แต่ฉันไม่ได้ตื่นเต้นกับมัน นี่คือปัญหาของฉัน: Heartbeat - จำกัด เพียงสองโหนดเท่านั้น ฉันต้องการมี 3+ Pacemaker - เป็นไปไม่ได้ที่จะกำหนดค่าโดยอัตโนมัติ คลัสเตอร์ต้องทำงานด้วยองค์ประชุมและจากนั้นก็ยังต้องการการกำหนดค่าด้วยตนเอง CoroSync - ไม่รองรับ unicast ผู้นำในกิจการใด ๆ ทำงานได้ดีแม้ว่าจะมีกำลังไฟทำให้การติดตั้งทำได้ยาก …

26 linux  high-availability  heartbeat  pacemaker  corosync 

เราต้องการฟังก์ชั่นขั้นสูงมากกว่าที่ ELB ให้ (ส่วนใหญ่เป็นการตรวจ L7) แต่ก็ไม่ชัดเจนว่าจะจัดการกับสิ่งต่าง ๆ เช่นการเต้นของหัวใจและความพร้อมใช้งานสูงด้วย haproxy โดยใช้ EC2 มีความเป็นไปได้สูงที่เราต้องการโหนด Haproxy 3 โหนดขึ้นไปในคลัสเตอร์ดังนั้นการเต้นของหัวใจที่ง่ายระหว่างสองโหนดจะไม่ทำงาน ดูเหมือนว่าจะมีเลเยอร์ heartbeat อยู่ข้างหน้าโหนด haproxy อาจเป็นไปได้ใช้ IPVS ได้ แต่จัดการกับการเปลี่ยนแปลงการกำหนดค่าเมื่อมีการเปลี่ยนแปลงคลัสเตอร์ EC2 (ไม่ว่าจะเป็นการเปลี่ยนแปลงโดยเจตนาเช่นการขยายหรือโดยไม่ตั้งใจ) โหนด EC2) ดูเหมือนไม่น่ารำคาญ โซลูชันจะครอบคลุมโซนความพร้อมใช้งานอย่างน้อยสองโซน ในการตอบคำถาม Qs: ไม่เซสชันไม่เหนียวเหนอะ และใช่เราต้องการ SSL แต่ในทางทฤษฎีสามารถจัดการได้โดยการตั้งค่าอื่นทั้งหมด - เราสามารถกำหนดปริมาณการใช้งาน SSL ไปยังตำแหน่งอื่นนอกเหนือจากปริมาณข้อมูลที่ไม่ใช่ SSL

25 amazon-ec2  load-balancing  haproxy  amazon-web-services  heartbeat 

ฉันต้องการจัดโครงสร้างเซิร์ฟเวอร์คลัสเตอร์ที่มีความพร้อมใช้งานสูง ตอนนี้ฉันต้องการทราบรายละเอียดเกี่ยวกับ keepalive และ heartbeat ความแตกต่างระหว่างทั้งสองคืออะไรและวิธีเลือกอย่างใดอย่างหนึ่ง

20 high-availability  heartbeat  keepalive 

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

20 cluster  heartbeat  pacemaker 

ฉันได้ค้นคว้าวิธีแก้ปัญหาความพร้อมใช้งานสูง (HA) สำหรับ MySQL ระหว่างศูนย์ข้อมูล สำหรับเซิร์ฟเวอร์ที่ตั้งอยู่ในสภาพแวดล้อมทางกายภาพเดียวกันฉันต้องการคู่หลักที่มี heartbeat (วีไอพีลอย) โดยใช้วิธีการใช้งานแบบพาสซีฟ Heartbeat มีทั้งการเชื่อมต่อแบบอนุกรมและการเชื่อมต่ออีเธอร์เน็ต ในที่สุดเป้าหมายของฉันคือการรักษาระดับความพร้อมใช้งานไว้เท่าเดิม แต่ระหว่างศูนย์ข้อมูล ฉันต้องการล้มเหลวแบบไดนามิกระหว่างศูนย์ข้อมูลทั้งสองโดยไม่มีการแทรกแซงด้วยตนเองและยังคงรักษาความสมบูรณ์ของข้อมูล จะมี BGP อยู่ด้านบน กลุ่มเว็บในสถานที่ทั้งสองซึ่งจะมีศักยภาพในการกำหนดเส้นทางไปยังฐานข้อมูลระหว่างทั้งสองฝ่าย หากการเชื่อมต่ออินเทอร์เน็ตลงไปที่ไซต์ 1 ลูกค้าจะกำหนดเส้นทางผ่านไซต์ 2 ไปยังเว็บคลัสเตอร์จากนั้นไปยังฐานข้อมูลในไซต์ 1 หากลิงก์ระหว่างไซต์ทั้งสองยังคงทำงานอยู่ กับสถานการณ์นี้เนื่องจากการขาดการเชื่อมโยงทางกายภาพ (ต่อเนื่อง) มีโอกาสมากขึ้นที่จะแยกสมอง หาก WAN ลงไประหว่างทั้งสองไซต์ VIP จะลงเอยที่ทั้งสองเว็บไซต์ ปัญหาที่อาจเกิดขึ้นอีกประการหนึ่งที่ฉันเห็นคือความยากในการปรับโครงสร้างพื้นฐานนี้ไปยังศูนย์ข้อมูลที่สามในอนาคต เลเยอร์เครือข่ายไม่ได้มุ่งเน้น สถาปัตยกรรมมีความยืดหยุ่นในขั้นตอนนี้ อีกครั้งฉันมุ่งเน้นเป็นวิธีการในการรักษาความสมบูรณ์ของข้อมูลเช่นเดียวกับความล้มเหลวอัตโนมัติกับฐานข้อมูล MySQL ฉันน่าจะออกแบบส่วนที่เหลือรอบนี้ คุณสามารถแนะนำโซลูชันที่พิสูจน์แล้วสำหรับ MySQL HA ระหว่างไซต์ที่มีความหลากหลายทางกายภาพสองไซต์ ขอบคุณที่สละเวลาอ่านข้อความนี้ ฉันหวังว่าจะอ่านคำแนะนำของคุณ

19 linux  mysql  disaster-recovery  heartbeat  linux-ha 

จากคนที่จัดการกับกลุ่มของตัวเอง (เช่นไม่ได้ใช้ / จ่ายเงินสำหรับ Amazon Autoscale, Rightscale, Scalr, ฯลฯ ) คุณจัดการกับอินสแตนซ์ของคุณบน EC2 และการจัดการความล้มเหลวได้อย่างไร (เช่น) ฉันสงสัยว่าคนส่วนใหญ่เพิ่งจบการเขียนสคริปต์ของตนเองที่โหลดกับ EC2 API อย่างที่ฉันสงสัย นั่นเป็นวิธีการของเรา: ใช้ Python Boto ในการตรวจสอบ / เริ่มต้น daemon ใหม่ที่ทำงานนอกสถานที่และรับฟัง UDP Keep-alives จากอินสแตนซ์ของเรา เมื่อล้มเหลวเราถ่ายภาพจำนวนลงทะเบียนเริ่มต้นอินสแตนซ์ใหม่ลบโวลุ่มเก่าและอื่น ๆ บ่อยครั้งที่เมื่อแฮ็คสคริปต์ของเราฉันคิดว่าจะต้องมีเครื่องมือโอเพนซอร์สบางอย่างที่จัดการกับปัญหาเหล่านี้แล้วและไม่มีข้อ จำกัด ของ (พูด) Scalr แต่ฉันกลับมาจาก Google เสมอ มือเปล่า (สิ่งต่าง ๆ เช่น Scalr นั้นค่อนข้าง จำกัด ในชุด / รุ่น …

13 amazon-ec2  failover  heartbeat  amazon-elastic-ip  scalr 

ฉันกำลังมองหาที่จะใช้บางสิ่งบางอย่างเช่น Heartbeat / Squid / Varnish / etc เพื่อปรับสมดุลปริมาณการรับส่งข้อมูลระหว่างอินสแตนซ์ apache ภายใน สิ่งนี้จะต้องเป็นซอฟต์แวร์ไม่ใช่ฮาร์ดแวร์เนื่องจากข้อมูลทั้งหมดของฉันทำงานบน VPS ฉันไม่ได้มีประสบการณ์มากมายในพื้นที่นี้ดังนั้นขออภัยถ้าฉันใช้คำศัพท์ที่ผิดและเลือกแพ็คเกจที่ไม่ถูกต้อง ฉันวาดบางสิ่งบางอย่างเพื่ออธิบายสิ่งที่ฉันเป็น ด้านสีเขียวคือลักษณะการตั้งค่าเริ่มต้นและด้านสีฟ้าคือลักษณะที่ปรากฏหลังจากเพิ่มอินสแตนซ์ apache เพิ่มเติมเนื่องจากการรับส่งข้อมูลเพิ่มขึ้น นี่อาจไม่ใช่สิ่งที่สิ่งเหล่านี้ทำงานได้ แต่โดยหลักแล้วฉันจะเพิ่ม IP ของตัวสร้างสมดุล / s ไปยัง DNS ของโดเมน จากนั้น balancer / s จะเห็นจำนวนการเชื่อมต่อที่อยู่ในแต่ละอินสแตนซ์ apache (ผ่านรายการการกำหนดค่าบางอย่างของ IP ภายในหรือ IP นิรันดร์) และกระจายการเชื่อมต่ออย่างเท่าเทียมกัน ในสีฟ้ามีบาลานเซอร์แห่งที่สองเพราะผมมั่นใจว่าในบางจุดบาลานเซอร์ก็ต้องการความช่วยเหลือเช่นกัน บางทีฉันอาจจะผิดเกี่ยวกับเรื่องนี้ แต่ฉันกำลังมองหาความช่วยเหลือเกี่ยวกับสิ่งที่ "balancer / s" ควรและแนวทางปฏิบัติที่ดีที่สุดเกี่ยวกับวิธีการตั้งค่าพวกเขา ความช่วยเหลือใด ๆ จะดีมาก

12 apache-2.2  load-balancing  squid  varnish  heartbeat