Cisco ACI Multi-Site Design (Part 3) - Stretched Fabric Failure Scenarios and Operational

Stretched Fabric Failure Scenarios and Operational

ในบทความนี้จะมาพูดถึง Failure Scenario ใน Stretched Fabric กันครับ ซึ่งจะมี 2 ประเด็นคือ
1. Loss of a Single APIC Controller
2. Split Fabric (All link connection loss between sites)

สามารถอ่านบทความก่อนหน้านี้เพื่อให้เข้าใจที่มาที่ไปของ Stretched Fabric ก่อนได้ครับ
Cisco ACI Multi-Site Designs (Part 1)
Cisco ACI Multi-Site Designs (Part 2) - Stretched Fabric Design

1. Loss of a Single APIC Controller

APIC ที่อยู่ภายใน Cluster จะมีการแชร์ data record database ระหว่างกัน ใน 1 Cluster มี APIC ได้ตั้งแต่ 3 - 31 Nodes โดยการใช้งานในระบบจริง (Production) แนะนำให้ใช้ 3 Nodes

Cisco APIC Cluster ใช้เทคโนโลยีจากฐานข้อมูลขนาดใหญ่ที่เรียกว่า sharding เพื่อกระจายข้อมูลระหว่างโหนดA APIC ภายใน Cluster ข้อมูลที่จัดเก็บใน APIC ถูกแบ่งเป็นส่วนๆ แต่ละส่วนจะถูกทำเป็นแบบจำลอง หรือ สำเนา (replicas) เก็บไว้บน APIC ทั้ง 3 ตัว สำหรับแต่ละส่วนของข้อมูลนั้น จะมี APIC หนึ่งตัวถูกเลือกให้เป็น Leader และที่เหลือก็เป็น Follower เฉพาะ Leader ของส่วนข้อมูลนั้นที่สามารถดำเนินการเขียนข้อมูลได้ กลไกนี้ทำให้มั่นใจในความสอดคล้องกันของข้อมูลและกระจายภาระงานระหว่าง APIC

เมื่อ APIC 1 ตัวไม่สามารถใช้งานได้ จะไม่มีผลกระทบกับ ACI Fabric ถ้ายังมี APIC ภายใน Cluster ทำงานอยู่อย่างน้อย 2 ตัว เรายังสามารถแก้ไข เปลี่ยนแปลงค่าคอนฟิกได้ และไม่มี configuration data loss เกิดขึ้น เพราะ 2 APIC ที่เหลือมีการ copy database และสำรอง configuration database เก็บเอาไว้ตามกลไลที่อธิบายไปด้านบน ตัว Leader จะกระจาย data base ให้กับ APIC ที่ยังอยู่ในระบบ

2. Split Fabric

เมื่อการเชื่อมต่อระหว่าง Site ไม่สามารถใช้งานได้ จะทำให้ Fabric ถูกแยกออกจากกัน (Split) ทำให้ APIC ที่ Site 2 ไม่สามารถคุยกับ APIC ฝั่ง Site 1ที่อยู่ใน Cluster เดียวกันได้

ในสถานการณ์นี้ Fabric ทั้ง 2 ฝั่ง ยังสามารถใช้งานได้ปกติ ไม่มีผลกระทบกับ traffic forwarding ทั้ง 2 Fabric ที่ถูกแยกออกจากกันยังสามารถเรียนรู้ New Endpoint ที่เข้ามาใน Fabric ของตัวเองได้ผ่าน Data Plane

เมื่อเรียนรู้ New Endpoint ตัว Leaf Switch จะอัพเดตข้อมูลของ New Endpoint ไปยัง Spine Switch ทำหน้าที่เป็น Spine Proxy และ Spine Switch ในแต่ละไซต์เรียนรู้เกี่ยวกับ New Endpoint ผ่านโปรโตคอล COOP (Co-operative key server) หลังจากการเชื่อมต่อระหว่างไซต์กลับมาใช้งานได้แล้ว ตัว Spine Switch ที่เป็น Spine Proxy ของทั้ง 2 Sites จะทำการอัพเดทและรวมข้อมูลกัน (Merge) จนมีข้อมูลของ identity proxy mapping database ที่สมบูรณ์ระหว่าง Spine Proxy ทั้ง 2 Sites

การทำงานของ APIC ในแต่ละ Site กรณี Split Fabric

APIC ใน Site 1  

ยังสามารถดำเนินการอ่านและเขียน policy ไปยัง ACI Fabric ได้ เรายังสามารถ login เข้าสู่ APIC ใน Site 1 และทำการคอนฟิก หรือ เปลี่ยนแปลง policy ได้ หลังจากการเชื่อมต่อระหว่าง 2 Sites กลับมาใช้งานได้  APIC Cluster จะ synchronize configuration sที่มีการเปลี่ยนแปลงไประหว่าง Fabric และ Push configuration ที่มีการเปลี่ยนแปลงนั้นลงไปที่อุปกรณ์ใน ACI Fabric

APIC ใน Site 2 

มันจะไม่ได้เป็น Leader เพราะมันเหลือตัวเดียวและไม่สามารถคุยกับ APIC ที่อยู่ฝั่ง Site 1 ได้ ดังนั้น APIC ฝั่ง Site 2 จะทำงานได้แค่ Read Only Mode เราไม่สามารถคอนฟิก หรือ เปลี่ยนแปลง policy ที่ APIC ของ Site 2 ได้

อย่างไรก็ตาม Site 2 ยังคงตอบสนองต่อ network event ต่างได้อยู่ เช่น workload migration , link failure , node failure หรือ switch reload เมื่อ Leaf Switch เรียนรู้ New Endpoint และอัพเดตไปหา Spine Proxy ผ่าน COOP แล้ว ยังมีการส่ง notification ไปยัง APIC ด้วย เพื่อให้เราสามารถดูข้อมูลของ New Endpoint ที่เรียนรู้เข้ามาล่าสุดได้จาก APIC ตัวเดียวที่ Site 2

การอัพเดทการเรียนรู้ New Endpoint ของ Site 2  ไปยัง APIC Leader

ระหว่างที่ APIC ของ Site 2 มีการอัพเดทข้อมูลไปยังตัว Leader (ซึ่งอยู่ใน Site 1) แล้วการเชื่อมต่อระหว่าง Site เกิดใช้งานไม่ได้ แล้วมีการเรียนรู้ New Endpoint มาจากตัว Leaf Switch ที่ Site 2 จะทำให้ Leaf Switch ที่ Site 2 ไม่สามารถส่งข้อมูลของ New Endpoint ไปหา APIC Leader ที่ Site 1 ได้ แต่เมื่อการเชื่อมต่อระหว่าง Site นั้นกลับมาใช้งานได้ปกติ ข้อมูลของ New Endpoint ที่ Leaf Switch ของ Site 2 ก็จะสามารถถูกส่งไปหา APIC Leader ที่ Site 1 ได้

สรุปสั้นๆ ก็คือ Split Fabric ไม่ได้ส่งผลกระทบต่อการใช้งาน ACI Fabric ยกเว้นแค่ APIC Site 2 จะอยู่ใน Read Only Mode

ติดตามตอนต่อไปเรื่อง Multiple Fabric Design นะครับ >>>

--------------------------------------------------------------------------------------------------------------------------

English Mode

You can read the previous article in order to understand before follow by below link
Cisco ACI Multi-Site Designs (Part 1)
Cisco ACI Multi-Site Designs (Part 2) - Stretched Fabric Design

Failure Scenarios and Operational Guidelines

The ACI switch and APIC controller software recover from various failure scenarios. Follow the guidelines below regarding best operating practices for handling various failure scenarios.

1. Loss of a Single APIC Controller

The APIC cluster distributes multiple replicated data records and functions across a federated cluster, providing services to the switching fabric as a single control element. The APIC supports from 3 to 31 nodes in a cluster. The current recommended minimum is a 3-node cluster. If the entire APIC cluster becomes unavailable, the ACI fabric continues to operate normally, except the fabric configuration cannot be modified.

The Cisco APIC cluster uses a technology from large databases called sharding to distribute data among the nodes of the cluster. Data stored in the APIC is portioned to shards. Each shard has three replicas that are stored in the three controller nodes. For each shard, one controller is elected as leader and the rest are followers. Only the leader of the shard can execute write operations to the shard. This mechanism ensures consistency of data and distributes the workload among all controller nodes.

The loss of one APIC controller in either site has no impact on the ACI fabric. With twoAPIC nodes alive, the cluster still has a quorum (two out of three) and administrators can continue to make configuration changes. There is no configuration data loss due to the APIC node being unavailable. The two APIC nodes retain redundant copies of the APICdata base, and the leadership role for the shards of the lost APIC controller is distributed among the remaining APIC controllers. As is the case with the non-stretched ACI fabric, best practice is to promptly bring the APIC cluster back to full health with all APIC nodes being fully healthy and synchronized.

2. Split Fabric

When all the connections between the sites are lost, the fabric splits into two fabrics. This scenario is referred to as split brain in some documents. In the figure below, the APIC controller in site 2 is no longer able to communicate with the rest of cluster.

In this situation the split fabrics continue to operate independently. Traffic forwarding is not affected. The two fabrics can learn the new endpoints through the data plane. At the site containing the VMM controller (site 1 in the figure above), endpoints are learned by the control plane as well. Upon learning new endpoints, leaf switches update the spine proxy. Independently of leaf switches, spine switches in each site learn of new endpoints via the co-operative key server (COOP) protocol. After the connections between sites are restored, the spine proxy database from the two sites merge and all spine switches have complete and identical proxy mapping databases.

The split fabric site with two APIC controller nodes (site 1 in the figure above) has quorum (two working nodes out of a cluster of three). The APIC in site 1 can execute policy read and write operations to the fabric. An administrator can log in to either APIC controller node in site 1 and make policy changes. After the link between the two sites recovers, the APIC cluster synchronizes configuration changes across the stretched fabric, pushing configuration changes into the concrete model in all the switches throughout the fabric.

When the connection between two sites is lost, the site with one APIC controller will be in the minority (site 2 in the figure above). When a controller is in the minority, it cannot be the leader for any shards. This limits the controller in site 2 to read only operations; administrators cannot make any configuration changes through the controller in site 2. However, the site 2 fabric still responds to network events such as workload migration, link failure, node failure, or switch reload. When a leaf switch learns a new endpoint, it not only updates the spine proxy via COOP but also sends notifications to controller so that an administrator can view the up-to-date endpoint information from the single controller in site 2. Updating endpoint information on the controller is a write operation. While the links between the two sites are lost, leaf switches in site 2 will try to report the newly learned endpoints to the shard leader (which resides in site 1 and is not reachable). When the links between the two sites are restored, the learned endpoints will be reported to controller successfully.

In short the split brain has no impact to the function of the fabric other than controller in site 2 is in the read only mode.

Reference : https://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/kb/b_kb-aci-stretched-fabric.html