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
