Versions Compared

Old Version 4

changes.mady.by.user Pavel Pereslegin

Saved on

compared with

New Version 5

changes.mady.by.user Pavel Pereslegin

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...


Pagesre-encryptionprocess description: 

This procedure usesitsownthread pool. 

Thread pool configured in IgniteConfiguration. 

  1. For each partition file. 

  2. The file is read page by page (blocked by IGNITE-11998?).

  3. For each page (following steps executed by manythreadsusinga producer-consumer pattern): 

    1. Page islocked from write operation into regular Ignite Durable Memory. 

    2. Page isread (from file) into memory. Note, this processdoesn't use regularoff-heapIgnite pages. 

    3. Page decrypted withthe previous key. 

    4. Page encrypted withthe new key. 

    5. Page is written intoa file. 

    6. Page id is added tothe re-encryptedpages set(Bloom filter as it has constant size). 

    7. Page is unlocked. 

  4. Progress ofre-encryptionis saved to WAL for failover after each X pages processed. X is configured in IgniteConfiguration. 

  5. Сompletion of partition re-encryption is accompanied by adding a WAL entry

  6. Process state: FINISHED. 

Motivation:  

  1. Memory footprint [Thread count]*[page size]

  2. Minor affect on regular data operations. 

  3. It doesn'tdisplace hot pages from RAM duringthe file scan process. 


Page decryption duringthe re-encryptionprocess: 

Duringthe re-encryptionprocess page may be encrypted withthe previous key OR with the new one.

To decrypt page we have to do the following steps: 

  1. Block page fromre-encryption. 

  2. Check inre-encryptedpages set is this page processed(see «Pagesre-encryptionprocess description» #3.6) 

  3. If page not reencrypted yet we use old key for decryption. 

  4. If page reported as reencrypted(Bloom filter may be false positive) we: 

    1. Try to decrypt page with new key. 

    2. If fail we should try to use old key.  

  5. Unblock page from reencryption. 

Process failover: 

Ifthe node fails in the middle ofthe re-encryptionprocess we should resumethe re-encryptionprocess on node startup. 

We should dothe following steps for started but not finished partition file: 

  1. Findthe last progress record in WAL. 

  2. Scan partition from the beginning to last progress record point and just add eache page to reencrypted pages set. 

  3. After it we have X pages that MAY BE reencrypted(and may be not). We should find fir not reencrypted page: 

    1. Trying to decrypt page with new key. 

    2. If fails then page is found.  
      We should continue reencryption process starting from it. 

Process completion: 

Administrator initiates process completion via interface by using “cache key removal” command. 
Design assume, administrator will check that all nodes successfully change cache key and reencrypt all pages and all required nodes are alive.

Cache group keys removal: 


Process start: 


Administrator initiates process via some kind of user interface(CLI, Visor, WebConsole, JMX, etc). 


Process description: 


Message is sent by discovery. 

Message should contain: 


  • new cache key hash. 


When server node processed message following actions are executed: 


  1. Received cache key hash compared with known cache key hash. 

  2. Previous cache key removed from MetaStore. 

Monitoring command:


Reencryption process state. 
  • Input: cache id. 
  • Output: 
    • List of Tuples6 
      • Node ID 
      • Reencryption process state. 
      • Count of partition to process. 
      • Current partition index. 
      • Current partition id. 
      • Count of processed page in current partition.