en:playground:opt_bras_l2:backup_l2_bras:start [Документация VAS Experts]

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
en:playground:opt_bras_l2:backup_l2_bras:start [2023/10/13 14:27] – ↷ Page moved from en:dpi:bras_bng:opt_bras_l2:backup_l2_bras:start to en:playground:opt_bras_l2:backup_l2_bras:start elena.krasnobryzhen:playground:opt_bras_l2:backup_l2_bras:start [2023/12/01 14:13] (current) – removed elena.krasnobryzh
Line 1: Line 1:
-====== BRAS L2 backup ====== 
-{{indexmenu_n>13}} 
  
-Backing up of BRAS in L2 mode involves the connecting up of two Stingray Service Gateways in one L2 broadcast domain. 
-One of them in Master mode and the other in Slave one. 
-Master SSG carries out traffic processing along with users authorization through the PCRF server. 
-Slave does not pass traffic through itself, dpdk interfaces are in the traffic standby mode (down). Subscribers information is synchronized through the PCRF server. 
-Slave monitors the availability and performance of the Master and when the last fails, Slave will activate (up) dpdk interfaces and start to process traffic automatically or manually. 
-An example of DPI connection and routes the traffic passes through it are presented in the diagram below. 
-{{ playground:opt_bras_l2:start:резервирование_bras_l2.png?nolink&400 |}} 
- 
-===== Database synchronization ===== 
-FastPCRF is responsible for synchronization, its configuration is described in the section [[en:dpi:bras_bng:replication:start|Replication of authorization data]]. 
-==== Configuring the SSG Master mode  ==== 
- 
-==== Configuring the SSG Slave mode ==== 
- 
-=== Algorithm description === 
-Stingray Service Gateway backup concept - MASTER-SLAVE (L2-BRAS): 
-  * 1. MASTER is running 99% of the time, it can be disabled or may fail 
-  * 2. When being recovered MASTER always treacherously proceed to process the traffic 
-  * 3. SLAVE just accepts replications from MASTER and saves them in UDR in 99% of the time   
-  * 4. There is a third party that switches traffic to MASTER or to SLAVE, depending on the current situation: 
-  *  4.1. MASTER is available, SLAVE is available, then the traffic will be switched to MASTER 
-  *  4.2. MASTER is available, SLAVE isn't, then the traffic will be switched to MASTER 
-  *  4.3. MASTER is not available, SLAVE is available, then the traffic will be switched to SLAVE 
-  *  4.4. MASTER and SLAVE are not available, then the traffic will be switched to MASTER 
- 
-MASTER-> SLAVE toggling: 
-  * 1. The third party detects that MASTER becomes unavailable and switches all the traffic to SLAVE 
-  * 2. Delays when switching are barely perceptible (physically and logically) due to 99% SLAVE's UDR contains replicated data 
- 
-Bootstrap MASTER'а (SLAVE is active and process traffic): 
-  * 1. MASTER has the fastdpi+fastpcrf services running and enabled (they were started on boot) 
-  * 2. MASTER detects that SLAVE is active and stores relevant data 
-  * 3. MASTER stops its fastdpi + fastpcrf services 
-  * 4. MASTER backups UDR on SLAVE and takes it back 
-  * 5. MASTER starts its fastdpi + fastpcrf 
-  * 6. A third party detects that the MASTER becomes available and switches the traffic to it 
- 
-Bootstrap MASTER'а (SLAVE is anavailable): 
-  * 1. MASTER has the fastdpi+fastpcrf services running and enabled (they were started on boot) 
-  * 2. MASTER determines that SLAVE is not available, considers that UDR it holds is more relevant than the one located on SLAVE, continues to work normally 
-  * 3. A third party detects that the MASTER becomes available and switches the traffic to it 
- 
-Bootstrap SLAVE'а (MASTER is active and process traffic): 
-  * 1. SLAVE has the fastdpi+fastpcrf services running and enabled (they were started on boot) 
-  * 2. SLAVE detects that MASTER is active and stores relevant data 
-  * 3. SLAVE stops its fastdpi + fastpcrf services 
-  * 4. SLAVE backups UDR on MASTER and takes it back 
-  * 5. SLAVE starts its fastdpi + fastpcrf 
-  * 6. SLAVE starts to replicate data 
- 
-Bootstrap SLAVE'а (MASTER is unavailable): 
-  * 1. SLAVE has the fastdpi+fastpcrf services running and enabled (they were started on boot) 
-  * 2. SLAVE detects that MASTER is unavailable, considers that UDR it holds is more relevant than the one located on the currently unavailable MASTER, continues to work normally 
-  * 3. A third party detects that SLAVE becomes available and switches the traffic to it