Nebula advertise_addrs หรือ static_host_map: เลือกตามเจ้าของ
แผนที่แบบคงที่ได้รับการดูแลโดยทุก peer ที่เรียกใช้ ส่วนที่อยู่ที่ประกาศนั้นเผยแพร่โดยโฮสต์ เลือกตามว่าใครรู้จุดปลายทาง
การตั้งค่า static_host_map และ advertise_addrs ต่างก็วางที่อยู่ไว้หน้า peer และตอบคำถามที่ต่างกัน อย่างหนึ่งคือไฟล์ภายในเครื่องที่ระบุที่อยู่ overlay และจุดปลายทาง underlay ที่จะเรียกใช้ อีกอย่างหนึ่งคือโฮสต์ที่บอกประภาคารของตนว่าจุดปลายทางเพิ่มเติมใดเข้าถึงได้ ความเป็นเจ้าของคือความแตกต่างที่แท้จริง แผนที่นั้นทุกคนที่ต้องการดูแล ส่วนการประกาศนั้นโฮสต์เองดูแล
ตัดสินใจตามว่าใครเป็นเจ้าของข้อมูล
| Setting | Where it lives | Best for |
|---|---|---|
static_host_map | Every peer that needs the entry | Bootstrap endpoints, deliberately fixed paths |
advertise_addrs | The host's own config | Endpoints the host cannot otherwise discover |
ทุก peer ที่เปลี่ยนแปลงในไฟล์คงที่ของแต่ละ peer คืองานบำรุงรักษาที่เติบโตตามกำลังสองของกองเรือ นี่คือเหตุผลเชิงปฏิบัติในการหันไปใช้การตั้งค่าอีกอย่างเมื่อโฮสต์เองรู้คำตอบ
คำถามเรื่องความเป็นเจ้าของยังทำนายว่าเกิดอะไรขึ้นเมื่อที่อยู่เปลี่ยน ด้วยแผนที่คงที่ ต้องมีคนจำทุก peer ที่ถือรายการเก่า ด้วยการประกาศ โฮสต์เผยแพร่จุดปลายทางใหม่และประภาคารของตนส่งต่อไป การเปลี่ยนแปลงจึงคงอยู่เฉพาะเครื่องที่ย้าย
Bootstrap ยังต้องใช้รายการคงที่
ไคลเอนต์ต้องเข้าถึงประภาคารอย่างน้อยหนึ่งแห่งก่อนจึงจะถามใครเกี่ยวกับ peer อื่นได้ การกระโดดครั้งแรกนั้นมาจากการค้นพบไม่ได้ จึงพึ่งพา รายการคงที่ในการกำหนดค่าของไคลเอนต์ ทำให้รายการเดียวนั้นถูกต้อง แล้วส่วนที่เหลือของ overlay ก็เรียนรู้ได้
รายการแผนที่จับคู่ที่อยู่ Nebula กับจุดปลายทาง IP หรือ DNS ที่เข้าถึงได้หนึ่งรายการขึ้นไปและพอร์ต การเก็บประภาคารไว้ที่นั่นเป็นเรื่องปกติ การเก็บทุก peer ไว้ที่นั่นคือรูปแบบที่แก่ตัวไม่ดี เพราะ peer ใหม่แต่ละตัวหมายถึงการแก้ไขไฟล์บนเครื่องที่คุณอาจไม่ได้ควบคุม เก็บรายการให้สั้นพอที่คนยังตรวจสอบได้ด้วยการอ่าน
ประกาศเมื่อโฮสต์รู้จุดปลายทาง
โฮสต์ที่อยู่หลังการส่งต่อพอร์ตเข้าถึงได้ที่ที่อยู่สาธารณะซึ่งไม่ได้กำหนดให้กับอินเทอร์เฟซใดของตนเอง มันไม่สามารถค้นพบที่อยู่นั้นได้ด้วยการมองตัวเอง advertise_addrs ทำให้มันเผยแพร่จุดปลายทางผ่านประภาคารของตน เพื่อให้ peer อื่นเรียนรู้เส้นทางที่ทำงานได้จริง การตั้งค่านี้มีอยู่เพราะโฮสต์เป็นฝ่ายเดียวที่รู้ว่าการแมปถูกสร้างขึ้น
ใช้ที่อยู่และพอร์ตที่ peer อื่นเข้าถึงได้จริง เหตุผลเดียวกันใช้กับโฮสต์ที่มีเส้นทางเครือข่ายหลายเส้น ซึ่งเส้นทางหนึ่งเหมาะกับ peer บนเครือข่ายหนึ่งๆ การประกาศคือข้อความเกี่ยวกับ underlay ไม่ใช่คำขอใดๆ เมื่อการแมปเปลี่ยน ให้อัปเดตการประกาศที่โฮสต์และปล่อยให้การค้นพบนำไป แทนที่จะแก้ไขไฟล์คงที่ทั่วทั้งกองเรือ
การประกาศไม่ใช่การเข้าถึงได้
การเผยแพร่จุดปลายทางไม่ได้สร้างกฎการส่งต่อของเราเตอร์ ไม่ได้เปิดไฟร์วอลล์ต้นทาง และไม่ได้ทำให้ชื่อ DNS แก้ได้ สิ่งเหล่านี้เป็นงานคนละส่วน และการประกาศที่ถูกต้องแต่ขาดการส่งต่อพอร์ตก็ก่อให้เกิดความล้มเหลวเดียวกับที่คุณพยายามแก้ การประกาศคือข้อกล่าวอ้างเรื่องการเข้าถึงได้ ไม่ใช่กลไกที่สร้างมันขึ้น
ตรวจสอบเส้นทางจากภายนอกก่อนโทษการค้นพบ peer ที่เรียนรู้จุดปลายทางแต่ทำ handshake ให้เสร็จไม่ได้มีปัญหาการกำหนดเส้นทางหรือการกรองบน underlay และการทำที่อยู่เดิมซ้ำในการตั้งค่าทั้งสองก็ไม่เปลี่ยนสิ่งนั้น
เก็บที่อยู่ overlay ให้แยกจากจุดปลายทาง
ใบรับรองของโหนดระบุที่อยู่ Nebula ของมัน ที่อยู่ที่ประกาศเป็นของเครือข่ายชั้นล่าง และเปลี่ยนได้โดยไม่แตะใบรับรอง การออกใบรับรองใหม่ด้วย IP overlay ที่ต่างออกไป เป็นการดำเนินการอีกอย่างหนึ่ง พร้อมผลที่ตามมาของมันเองต่อทุกความสัมพันธ์ความไว้วางใจที่ปักหมุดอันเก่าไว้ เก็บการเปลี่ยนแปลงทั้งสองแยกกันใน runbook ไม่เช่นนั้นการย้ายจุดปลายทางจะถูกบันทึกเป็นการออกใหม่
เมื่อการคัดแยกข้อมูลติดขัด ให้แยกสองชั้นอย่างชัดเจน การค้นพบคืนจุดปลายทางที่คาดไว้หรือไม่ และ handshake ไปถึงมันหรือไม่ หากการค้นพบถูกต้องและแพ็กเก็ตล้มเหลว ปัญหาอยู่ใต้ overlay หากการค้นพบผิด ปัญหาอยู่ในแผนที่หรือการประกาศ และการแก้ไขก็อยู่ที่นั่น