Reinhard Buendgen wrote: >As for the recommendation, I am not sure where it is written. But I >remember that there was a time where IBM would only sell at least two to >enforce/encourage redundancy. But I am not sure whether this is still >true fro small systems.
I believe it's possible to order every IBM Z and IBM LinuxONE machine with even a single Crypto Express feature. The configuration tool will warn against it, but it's possible. >Anyway one reason to have redundancy within you system is the support >of non-disruptive service to your adapters. I guess planned maintenance >is an event that is more frequent then actual unplanned failures. Sure, and that all broadly makes sense, which is why IBM warns that a single feature is not generally recommended. (I can think of a couple exceptions, which is probably why IBM allows such orders to my knowledge.) But it's a very separate question whether it makes sense to configure two domains per Linux guest. Linux guests can bounce up and down all the time, planned or unplanned, and you must plan for that reality and deal with it already, especially in a production environment. >But again if your HA failover solution is really fast, you can trigger a >planned failover ... well that add sto the management bill and you will >observe some outage that is certainly longer than the retry the kernel >performs within the system... Right, but you've already got to prepare for that and do that for myriad reasons, "all the time." >once a file system is mounted on a PAES encrypted dm-crypt volume you no >longer need the CryptoExpress adapter as long as your Linux system runs >in that guest. Protected key dm-crypt only needs the CryptoExpress >adapters when the dm-crypt volume gets is opened (which must happen >before the mount step). For the dm-crypt open operation with the PAES >cipher a CCA secure key is provided to the kernel and the kernel >transforms this secure key (with the help of the Crypro Express adapter) >into a protected key. Once dm-crypt knows the protected key, it no >longer need the secure key or the crypto adapter, it uses the protected >key instead. This property is also nice if you want to change the master >keys of your adapter. If you can do that during a period where you do >not need to open a dm-crypt device, it will work concurrently to using >your volumes. That's great news. So, to summarize, a whole CCA domain can go offline for whatever reason(s), and the Linux guest that depends on that CCA domain for dm-crypt/LUKS2 will keep chugging along as long as its file systems are mounted (and as long as it doesn't need some other vital-to-the-guest service from the CCA domain). Then that Linux guest will be able to mount additional encrypted volumes when the CCA domain comes back online and is otherwise suitably configured. In other words, with reasonable assumptions, a temporary CCA domain outage is nondisruptive to its Linux guest. That's awesome! Anyway, "Spend your CCA domains wisely" if you think it'll be a constraining number, but I think there's a good argument that one CCA domain per Linux guest can be a perfectly reasonable, viable, production configuration. -------------------------------------------------------------------------------------------------------- Timothy Sipples IT Architect Executive, Digital Asset & Other Industry Solutions, IBM Z & LinuxONE -------------------------------------------------------------------------------------------------------- E-Mail: [email protected] ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www2.marist.edu/htbin/wlvindex?LINUX-390
