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. 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.
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...
> If there's only one and that card fails, does the file system get
unmounted
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.
So you want the crypto adapters to be available when you open the
volumes (typically at system start) and here it comes in handy if there
is a backup adapter in case you primary does not work for some reason
because otherwise you cannot get to mounting your FS.
In Linux too, you can set crypto adapter domains offline (see man
chzcrypt for details). Note this just tells the kernel to no longer use
the adapter or adapter domain. It does not have any effect on the crypto
HW or FW. As for looking at the state of your crypto adapters (domains)
lszcrypt is your friend.
-Reinhard
On 22.01.20 08:12, Timothy Sipples wrote:
Reinhard Buendgen wrote:
The number 680 just reflects the recommendation to achieve
crypto redundancy per configuration (once configured properly
the Linux kernel will do the rest).
Where is that recommendation coming from? Is there any nuance to it, and
does it still make sense?
As for the level of redundancy (device redundancy, HA cluster, or DR
cluster), it is the customers choice to decide the kind of penalty (ms,
secs , mins) he or she is willing to accept in case of a the failure of
a single resource. Also note that for certain workloads (workloads
managing a shared state, e.g. R/W data bases), HA clusters may be
pretty complex and impact performance.
Sure, but "What else is new?" A single Linux guest has a single kernel, and
it's a single point of failure -- a relatively big one. Metaphorically
speaking, having a second bucket positioned at the same well doesn't help
me water the plants any better when I have no water, and I must already
plan for having no water.
Moreover, if you are incurring these various overheads, penalties, and
complexities already -- as you typically would be in a production
deployment, unavoidably -- does it still make sense to double the
consumption rate of a somewhat finite resource (CCA domains), particularly
if it's constraining, and end up with a *quad* (a pair of Linux guests,
clustered, sitting atop 4 CCA domains)? And if a "quad" makes sense there,
does it make equal sense to double every component everywhere in the
delivery of application services? For example, if you're running a pair of
clustered Java application servers, shouldn't you actually have *four* of
them (two running in each Linux guest)? Then, if one Java application
server instance fails, you still have both Linux guests/kernels providing
service. That's fundamentally the same redundancy idea, right? (And we're
just getting warmed up. ;))
Marcy Cortes wrote:
If there's only one and that card fails, does the file system get
unmounted
and/or throw errors? Or does it continue on and just have issues at next
reboot?
That's a really great question, too. It might not be as dire an event as
one might ordinarily think with protected key operations (only, and fully
instantiated), but I'll let Reinhard chime in.
Is there any way to test card failure?
How about just issuing a VARY OFFLINE CRYPTO command in z/VM? In a test
z/VM LPAR, of course! Here's the syntax:
Q CRYPTO DOMAIN
to find the list of Crypto Express adapters and their domains. You should
see something like "CEX6C" or "CEX7C" for the Crypto Express features that
are configured in CCA mode. So let's suppose that "AP 013" is the Crypto
Express adapter that you want to vary offline. This command should do that:
VARY OFFLINE CRYPTO AP 13
--------------------------------------------------------------------------------------------------------
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
----------------------------------------------------------------------
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
