1. Capacity manager
1.1. Diferences between Gen 1 and Gen 2
1.1.1. Aditional layer Virtual Storage Pool
1.1.1.1. Over Provisioning factor by default is unlimited
1.1.1.1.1. valid values for OP factor 2-1000. The 0 is unlimited
1.1.1.2. User specifyes the Physical capacity and it allocates the raw capacity
1.1.1.2.1. There is a dynamic Uber allocating. Initial allocating for Data BEVs is 15%
1.1.1.2.2. WrC size is static and depens on initial SP size
1.1.1.2.3. MD Bev increases dynamicaly
1.1.1.3. Minimal Storage Pool Size depends on number of Nodes
1.1.1.4. Spare capacity in devices and Nodes
1.1.1.4.1. System doesn't requiers the real physical spare nodes
1.1.1.4.2. System allows to work with 4 and 10 nodes but it should not be used because there are no spare nodes. It should be 4+2 or 10 +2
1.1.1.4.3. System recalculates the spare capacity automaticaly after adding/removing devices
1.1.2. There is no COMB. MUs manage capacity
1.2. Efficiency for Gen 2
1.2.1. 2+2 requiers less nodes but efficiency only 50%
1.2.1.1. But for good expiriance it should be 6 nodes
1.2.2. 8+2 is a prefereble scheme. It has 80 % of efficiency
1.2.2.1. It needs 12 nodes
1.3. New statuses for Data protection
1.3.1. Protected
1.3.2. Single Degraded
1.3.3. Critical Degraded
1.3.4. Failed
1.4. Usable capacity. There is an inconsistancy between implementation and aritecture.
2. Counters
2.1. Physical Counters
2.2. Logical Counters
2.2.1. PDS sends report one time per minute
2.2.2. PDS service restart looses the data
2.2.3. Counter Persistancy on MDM side
2.3. Performance Counters
3. File
3.1. File contains info about one PD
3.2. Max file size 30 MB
3.3. File updates only when state was changed
3.4. History max 3 files
3.5. Poling interval 1 sec
3.6. File has header with text information.
3.7. Disconnected PDS or DGWT leavs the matrix
4. System behavior
4.1. Desision after 5 sec
4.2. Cases
4.2.1. 1:1
4.2.1.1. one PDS is disconnected from one DGWT. MDM will allocate new slices if it can, and approve degraded writes otherwise.
4.2.2. 1:n
4.2.2.1. one PDS is disconnected from multiple DGWTs. The MUs will be moved to other PDSs.
4.2.3. m:1
4.2.3.1. many PDSs are disconnected from one DGWT. The DGWT is failed.
4.2.4. m:n
4.2.4.1. many PDSs are disconnected from many DGWTs. If the system transits to this state from the previous two, the PDS / DGWT will be unfailed. The affected VPs will be disabled to protect them.
4.2.5. Back to Connected state
4.2.6. MDM Reconstruct no persistancy for matrix. The decision was made is in repository
4.2.7. There is no Proxy PDS for this version
4.2.8. IO issues not for this version
5. Events and Alerts
6. Automation tests
6.1. Building blocks
6.1.1. C-Matrix file parser
6.1.1.1. Data class for connectivity matrix
6.1.1.2. Search file in master MDM (use stab for the begining)
6.1.1.3. It should take last matrix
6.1.1.3.1. It should get Master MDM
6.1.1.4. Data class for setting expected state of matrix
6.1.2. Uber Dump file parser
6.1.3. Connectivity blocker for blocking specific DGWTs
6.1.3.1. needs to search in the Spark. It would be beter to setup connectivity by Data class expected
6.1.4. SDBG parser
6.1.5. Events searcher (showevent.py)
6.1.6. MU balancer checking
6.2. Test scenarios
6.2.1. It needs 2 or more PDs
6.2.2. MM mode and connection issues
6.2.3. IP roles
6.2.4. Add/Remove PDS
6.2.5. Add/Remove DGWT
6.2.6. 1:1, m:1, 1:n, m:n All scenarios should have restore
6.2.7. MDM switch ovnership
6.2.8. PD active/Inactive
6.2.9. Upgrade of component how it affects the matrix?
6.2.10. Run IO and validate the journal in the end of test
6.2.11. The scenario can be writen now without C Matrix it should fail
6.2.12. IPv4/IPv6
7. Counters
7.1. Requirements are not ready
7.1.1. PD
7.1.2. System