Does anyone know if it''s OK to do zfs send/receive between zpools with different ashift values? -- Andrew Gabriel
On 07/26/11 10:14, Andrew Gabriel wrote:> Does anyone know if it''s OK to do zfs send/receive between zpools with > different ashift values?The ZFS Send stream is at the DMU layer at this layer the data is uncompress and decrypted - ie exactly how the application wants it. The ashift is a vdev layer concept - ie below the DMU layer. There is nothing in the send stream format that knows what an ashift actually is. -- Darren J Moffat
> > The ZFS Send stream is at the DMU layer at this layer the data is > uncompress and decrypted - ie exactly how the application wants it. >Even the data compressed/encrypted by ZFS will be decrypted? If it is true, will it be any CPU overhead? And ZFS send/receive tunneled by ssh becomes the only way to encrypt the data transmission? Thanks. Fred
On 07/26/11 11:28, Fred Liu wrote:>> The ZFS Send stream is at the DMU layer at this layer the data is >> uncompress and decrypted - ie exactly how the application wants it. >> > > Even the data compressed/encrypted by ZFS will be decrypted?Yes, which is exactly what I said. All data as seen by the DMU is decrypted and decompressed, the DMU layer is what the ZPL layer is built ontop of so it has to be that way. > If it is true, will it be any CPU overhead? There is always some overhead for doing a decryption and decompression, the question is really can you detect it and if you can does it mater. If you are running Solaris on processors with built in support for AES (eg SPARC T2, T3 or Intel with AES-NI) the overhead is reduced significantly in many cases. For many people getting the stuff from disk takes more time than doing the transform to get back your plaintext. In some of the testing I did I found that gzip decompression can be more significant to a workload than doing the AES decryption. So basically yes of course but does it actually mater ?> And ZFS send/receive tunneled by ssh becomes the only way to encrypt the data transmission?That isn''t the only way. -- Darren J Moffat
> > Yes, which is exactly what I said. > > All data as seen by the DMU is decrypted and decompressed, the DMU > layer > is what the ZPL layer is built ontop of so it has to be that way. >Understand. Thank you. ;-)> > There is always some overhead for doing a decryption and decompression, > the question is really can you detect it and if you can does it mater. > If you are running Solaris on processors with built in support for AES > (eg SPARC T2, T3 or Intel with AES-NI) the overhead is reduced > significantly in many cases. > > For many people getting the stuff from disk takes more time than doing > the transform to get back your plaintext. > > In some of the testing I did I found that gzip decompression can be > more > significant to a workload than doing the AES decryption. > > So basically yes of course but does it actually mater ? >It is up to how big the delta is. It does matter if the data backup can not be finished within the required backup window when people use zfs send/receive to do the mass data backup. BTW adding a sort of off-topic question -- will NDMP protocol in Solaris will do decompression and decryption? Thanks.> > And ZFS send/receive tunneled by ssh becomes the only way to encrypt > the data transmission? > > That isn''t the only way. > > > --Any alternatives, if you don''t mind? ;-) Thanks. Fred
Op 26-07-11 12:56, Fred Liu schreef:> Any alternatives, if you don''t mind? ;-)vpn''s, openssl piped over netcat, a password-protected zip file,... ;) ssh would be the most practical, probably. -- No part of this copyright message may be reproduced, read or seen, dead or alive or by any means, including but not limited to telepathy without the benevolence of the author.
On 07/26/11 11:56, Fred Liu wrote:> It is up to how big the delta is. It does matter if the data backup can not > be finished within the required backup window when people use zfs send/receive > to do the mass data backup.The only way you will know of decrypting and decompressing causes a problem in that case is if you try it on your systems. I seriously doubt it will be unless the system is already heavily CPU bound and your backup window is already very tight.> BTW adding a sort of off-topic question -- will NDMP protocol in Solaris will do > decompression and decryption? Thanks.My understanding of the NDMP protocol is that it would be a "translator" that did that it isn''t part of the core protocol. The way I would do it is to use a T10000C tape drive and have it do the compression and encryption of the data. http://www.oracle.com/us/products/servers-storage/storage/tape-storage/t10000c-tape-drive-292151.html The alternative is to have the node in your NDMP network that does the writing to the tape to do the compression and encryption of the data stream before putting it on the tape.>>> And ZFS send/receive tunneled by ssh becomes the only way to encrypt >> the data transmission? >> >> That isn''t the only way. >> >> >> -- > > Any alternatives, if you don''t mind? ;-)For starters SSL/TLS (which is what the Oracle ZFSSA provides for replication) or IPsec are possibilities as well, depends what the risk is you are trying to protect against and what transport layer is. But basically it is not provided by ZFS itself it is up to the person building the system to secure the transport layer used for ZFS send. It could also be write directly to a T10k encrypting tape drive. -- Darren J Moffat
> > The only way you will know of decrypting and decompressing causes a > problem in that case is if you try it on your systems. I seriously > doubt it will be unless the system is already heavily CPU bound and > your > backup window is already very tight. >That is true.> > My understanding of the NDMP protocol is that it would be a > "translator" > that did that it isn''t part of the core protocol. > > The way I would do it is to use a T10000C tape drive and have it do the > compression and encryption of the data. > > http://www.oracle.com/us/products/servers-storage/storage/tape- > storage/t10000c-tape-drive-292151.html > > The alternative is to have the node in your NDMP network that does the > writing to the tape to do the compression and encryption of the data > stream before putting it on the tape. >I see. T10000C is a monster to have if possible ;-). And doing the job on NDMP node(Solaris) needs extra software, is it correct?> > For starters SSL/TLS (which is what the Oracle ZFSSA provides for > replication) or IPsec are possibilities as well, depends what the risk > is you are trying to protect against and what transport layer is. > > But basically it is not provided by ZFS itself it is up to the person > building the system to secure the transport layer used for ZFS send. > > It could also be write directly to a T10k encrypting tape drive. > > --Gotcha! Many thanks. Fred
On 07/27/11 10:24, Fred Liu wrote:>> The alternative is to have the node in your NDMP network that does the >> writing to the tape to do the compression and encryption of the data >> stream before putting it on the tape. >> > > I see. T10000C is a monster to have if possible ;-). > And doing the job on NDMP node(Solaris) needs extra software, is it correct?I believe so, also it is more than just the T10000C drive you need it needs to be in a library and you also need the Oracle Key Management system to be able to do the key management for it. -- Darren J Moffat
> > I believe so, also it is more than just the T10000C drive you need it > needs to be in a library and you also need the Oracle Key Management > system to be able to do the key management for it. >Yes. Single T10000C is not a big deal. I mean the whole backup system(tape lib & drive, backup software & network) which needs magnitude like T10000C grade is a monster. It seems encryption is not integrated into NDMP protocol stack. Thanks. Fred
On Tue, Jul 26, 2011 at 03:28:10AM -0700, Fred Liu wrote:> > > > > The ZFS Send stream is at the DMU layer at this layer the data is > > uncompress and decrypted - ie exactly how the application wants it. > > > > Even the data compressed/encrypted by ZFS will be decrypted? If it is true, will it be any CPU overhead? > And ZFS send/receive tunneled by ssh becomes the only way to encrypt the data transmission?Even if zfs send/recv will work with encrypted and compressed data you still need some secure tunneling. Storage encryption is not the same as network traffic encryption. -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20110727/5bced269/attachment.bin>
On 07/27/11 12:51, Pawel Jakub Dawidek wrote:> On Tue, Jul 26, 2011 at 03:28:10AM -0700, Fred Liu wrote: >> >>> >>> The ZFS Send stream is at the DMU layer at this layer the data is >>> uncompress and decrypted - ie exactly how the application wants it. >>> >> >> Even the data compressed/encrypted by ZFS will be decrypted? If it is true, will it be any CPU overhead? >> And ZFS send/receive tunneled by ssh becomes the only way to encrypt the data transmission? > > Even if zfs send/recv will work with encrypted and compressed data you > still need some secure tunneling. Storage encryption is not the same as > network traffic encryption.Indeed, plus you don''t necessarily want to always have your backups encrypted by the same keys as the live data (ie the policy for key management and retention could be different on purpose). -- Darren J Moffat