continue of previous mail...
The same method rethrows an exception which will lead to failure of an
metrics exporter. The method should return some numeric value which
indicates the failure.
On Wed, Oct 28, 2020 at 3:09 PM Andrey Gura wrote:
>
> Hi there,
>
> I accidentally stumbled upon a
Andrey,
thanks for your comment.
I will fix this problem shortly.
ср, 28 окт. 2020 г. в 15:10, Andrey Gura :
>
> Hi there,
>
> I accidentally stumbled upon a potential performance problem in this commit.
>
> CacheGroupMetricImpls.getPagesLeftForReencryption method contains at
> least two
Hi there,
I accidentally stumbled upon a potential performance problem in this commit.
CacheGroupMetricImpls.getPagesLeftForReencryption method contains at
least two problems:
- Relatively major: In order to calculate a value for one metric the
method has O(N) complexity (N is number of
Hello folks,
thanks to everyone who joined the review, greatly appreciate your
helpful comments.
If there is no objection, we will merge this patch [1] shortly.
[1] https://github.com/apache/ignite/pull/7941
пн, 5 окт. 2020 г. в 15:30, Maksim Stepachev :
>
> Hi,
>
> I'm going to do it.
>
> сб,
Hi,
I'm going to do it.
сб, 3 окт. 2020 г. в 21:47, Alex Plehanov :
> Hello guys,
>
> I've finished the review and approved the patch.
> Anybody else would like to review it?
>
> пн, 28 сент. 2020 г. в 11:38, Pavel Pereslegin :
>
> > Hello, Maksim!
> >
> > I am currently working on a review
Hello guys,
I've finished the review and approved the patch.
Anybody else would like to review it?
пн, 28 сент. 2020 г. в 11:38, Pavel Pereslegin :
> Hello, Maksim!
>
> I am currently working on a review notes from Alexey Plekhanov, will
> let you know when I finish.
>
> пн, 28 сент. 2020 г. в
Hello, Maksim!
I am currently working on a review notes from Alexey Plekhanov, will
let you know when I finish.
пн, 28 сент. 2020 г. в 11:04, Maksim Stepachev :
>
> Hi, Pavel.
>
> As I see, the ticket [https://issues.apache.org/jira/browse/IGNITE-12843]
> is "PATCH AVAILABLE". Is this ticket
Hi, Pavel.
As I see, the ticket [https://issues.apache.org/jira/browse/IGNITE-12843]
is "PATCH AVAILABLE". Is this ticket finished?
чт, 13 авг. 2020 г. в 13:49, Pavel Pereslegin :
> Hello all.
>
> I'm working on TDE cache group key rotation [1] and I have a couple of
> questions about partition
Hello all.
I'm working on TDE cache group key rotation [1] and I have a couple of
questions about partition re-encryption.
As described in the wiki [2], the process of re-encryption at the
moment consists of sequentially marking memory pages as dirty, this
process looks not resource-intensive.
Hello,
I'll expand the answer a bit about calculating CRC, the problem is not
that it is calculated twice, but that now for encrypted pages,
EncryptedFileIO checks physical integrity, and FilePageStore checks
the correctness of the encryption key, but from my point of view, it
should be vice
Hello,
> 10. Question - CRC is read in two places encryptionFileIO and
> filePageStore - what should we do with this?
We need to calculate the CRC of encrypted data, because we may be
using the wrong encryption key to decrypt data, in which case we will
not understand if the physical integrity
Hello Nikolay,
> > 10. Question - CRC is read in two places encryptionFileIO and
> filePageStore - what should we do with this?
>
> filePageStore checks CRC of the encrypted page. This required to confirm
> the page not corrupted on the disk.
> encryptionFileIO checks CRC of the decrypted
Hello, Maksim.
Thanks for the summary.
From my point of view, we should focus on Phase3 implementation and then do the
refactoring for some specific SPI implementation.
> 8. Question - why we add a lot of system properties?
Can you, please, list system properties that should be moved to the
Hello everyone, yesterday we discussed the implementation of TDE over a
conference call. I added a summary of this call here:
1. The wiki documentation should be expanded. It should describe the
steps - how it works under the hood. What are the domain objects in the
implementation?
2.
Hello, Maksim.
For implementation, I chose so-called "in place background
re-encryption" design.
The first step is to rotate the key for writing data, it only works on
the active cluster, at the moment..
The second step is re-encryption (to remove previous encryption key).
If node was restarted
Hi!
Do you have any updates about this issue? What types of implementations
have you chosen (in-place, offline, or in the background)? I know that we
want to add a partition defragmentation function, we can add a hole to
integrate the re-encryption scheme. Could you update your IEP with your
Nikolay, Alexei,
thanks for your suggestions.
Offline re-encryption does not seem so simple, we need to read/replace
the existing encryption keys on all nodes (therefore, we should be
able to read/write metastore/WAL and exchange data between the
baseline nodes). Re-encryption in maintenance
пн, 25 мая 2020 г. в 12:00, Nikolay Izhikov :
> > This willl takes us to the re-encryption using full rebalancing
>
> Rebalance will require 2x efforts for reencryption
>
> 1. Read and send data from supplier node.
> 2. Reencrypt and write data on demander node.
>
> Instead of
>
> 1. Read,
> This willl takes us to the re-encryption using full rebalancing
Rebalance will require 2x efforts for reencryption
1. Read and send data from supplier node.
2. Reencrypt and write data on demander node.
Instead of
1. Read, reencrypt and write data on «demander» node.
> 25 мая 2020 г., в
For me, the one big disadvantage for offline re-encryption is the
possibility to run out of WAL history.
If an re-encryption takes a long time we will get full rebalancing with
partition eviction.
This willl takes us to the re-encryption using full rebalancing, proposed
by me earlier.
пн, 25
> And definitely this approach is much simplier to implement
I agree.
If we allow to made nodes offline for reencryption then we can implement a
fully offline procedure:
1. Stop node.
2. Execute some control.sh command that will reencrypt all data without
starting node
3. Start node.
Pavel,
> Can you explain why such restriction is necessary ?
Reencryption should have a minimum impact on the cluster.
> Most likely having a currently re-encrypting node serving only demand
> requests will have least preformance impact on a grid.
Current design assumes that reencryption will started
And definitely this approach is much simplier to implement because all
corner cases are handled by rebalancing code.
пн, 25 мая 2020 г. в 11:16, Alexei Scherbakov :
> I mean: serving supply requests.
>
> пн, 25 мая 2020 г. в 11:15, Alexei Scherbakov <
> alexey.scherbak...@gmail.com>:
>
>>
I mean: serving supply requests.
пн, 25 мая 2020 г. в 11:15, Alexei Scherbakov :
> Nikolay,
>
> Can you explain why such restriction is necessary ?
> Most likely having a currently re-encrypting node serving only demand
> requests will have least preformance impact on a grid.
>
> пн, 25 мая 2020
Nikolay,
Can you explain why such restriction is necessary ?
Most likely having a currently re-encrypting node serving only demand
requests will have least preformance impact on a grid.
пн, 25 мая 2020 г. в 11:08, Nikolay Izhikov :
> Hello, Alexei.
>
> I think we want to implement this feature
Hello, Alexei.
I think we want to implement this feature without nodes restart.
In the ideal scenario all nodes will stay alive and respond to the user
requests.
> 24 мая 2020 г., в 15:24, Alexei Scherbakov
> написал(а):
>
> Pavel Pereslegin,
>
> I see another opportunity.
> We can use
Pavel Pereslegin,
I see another opportunity.
We can use rebalancing to re-encrypt node data with a new key.
It's a trivial procedure for me: stop a node, clear database, change a key,
start node and wait for rebalancing to complete.
Data will be re-encrypted during rebalancing.
Did I miss
Folks,
Just keeping you informed: I and my colleagues are highly interested in TDE
in general and keys rotations specifically, but we don't have enough time
so far.
We'll dive into this feature and participate in reviews next month.
--
Best Regards,
Ivan Rakov
On Sun, May 17, 2020 at 10:51 PM
Hello, Alexey.
> is the encryption key for the data the same on all nodes in the cluster?
Yes, each encrypted cache group has its own encryption key, the key is
the same on all nodes.
> Clearly, during the re-encryption there will exist pages
> encrypted with both new and old keys at the same
Pavel, Anton,
How do you see the whole key rotation procedure will work? Clearly, during
the re-encryption there will exist pages encrypted with both new and old
keys at the same time. Will a node continue to re-encrypt the data after it
restarts? If a node goes down during the re-encryption, but
+1 to "In place re-encryption".
- It has a simple design.
- Clusters under load may require just load to re-encrypt the data.
(Friendly to load).
- Easy to throttle.
- Easy to continue.
- Design compatible with the multi-key architecture.
- It can be optimized to use own WAL buffer and to
Hello Igniters.
Recently, master key rotation for Apache Ignite Transparent Data
Encryption was implemented [1], but some security standards (PCI DSS
at least) require rotation of all encryption keys [2]. Currently,
encryption occurs when reading/writing pages to disk, cache encryption
keys are
32 matches
Mail list logo
