Q:DEVD (virtual printer device) clean-up on iSeries

Question: I need help to get an overview of the virtual printer device descriptions (DEVDs) on an IBM mid-range host (AS/400, iSeries). Also, how do I delete a virtual printer device that is no longer needed?

Answer: The following answer has been written with the IAPS TNe in mind, but most of it is applicable to the management of DEVDs for all kinds of host sessions - TNe on other products, IPDS, and so on. Special information about TNe: In general, when you create a TNxxxx printer, the host will create both a virtual printer device (DEVD/WTR) and an output queue (OUTQ) with the same name - shown as xxx below. When a TNe session is activated on the IAPS, it either uses an existing device and queue on the host, or makes the host create the device and queue, using "Device Description" for the Session configuration. And, activating the session on the IAPS automatically makes the device active on the host. So there is no need to vary the device on or start the writer via commands on the host. You should always strive to create naming standards and stick to them, so that you don't end up with objects you no longer use cluttering up the host. But you can't always prevent clutter, especially when you are experimenting while learning how to best exploit the product. Therefore, you may need to delete the DEVD/WTR and OUTQ, and if so, this must be done manually on the host. 1. Getting an overview To see an overview of the virtual printers on the host, use the following command: WRKDEVD *VRTPRT Press F14 to see the status of each printer device. Note that the terminology used for different kinds of status depends on the user-interface you use to access the host. What you are looking for is whether the status is 'available' or 'unavailable' (or 'powered off or not yet available') - or, if another terminology is used, whether the status is 'varied on' or 'varied off'. Note: If you press F21 and choose assistance level 1, the terms having to do with availability are used. If you choose level 2 or 3, the terms varied on and varied off are used. 2. Make device unavailable - or vary it off Before deleting a device, the status must be 'Varied Off' or 'Unavailable' or 'Powered off or not yet available' (in other words, the device is not in use at the moment). From the status list displayed after pressing F14, use option '2' to make individual devices unavailable or vary them off. 3. Delete device - and possibly the queue From the WRKDEVD *VRTPRT menu, select option '4'=Delete to delete a device. If the output queue is empty, it will be deleted when you delete the device. 4. Delete output queue: first clear the queue of spooled files If the output queue is not empty, deleting the printer device will leave the used output queue untouched. To delete that as well you first need to be sure that the output queue is empty. You can clear the output queue of spooled files either by deleting them or by moving the spooled files to another output queue. To see the spooled files in the queue, use the command: WRKOUTQ xxx - where xxx is the queue name. To delete all spooled files on an output queue, use the command: CLROUTQ xxx - where xxx is the queue name. Make sure no one will miss the spooled files first., because there is probably no back up of spooled files. To move several spooled files, first place a '2' in front of all the spooled files (do not press Enter yet!) and then type OUTQ(yyy) on the command line. When you press Enter you move all the spooled files that are marked with '2' onto the output queue called yyy. 5. Delete output queue Use the command: DLTOUTQ xxx

Notes

Great video of Richard Dawkins, will be seeing him in June in Dublin.

Great Vid

Flexible Storage Replication

Filed under: Uncategorized — archangel @ 9:06 pm

I have recently been looking quite a lot at different storage setups including storage replication and have been so far mostly relying on running rsync to copy a file system to an appropriate secondary host. For large file systems – either with a lot of files or simply a lot of changing data, this is slow and resource intensive. Not really a problem in some cases, but very problematic if you want your secondary system to have very current data. If you want to cobble something together yourself from commodity hardware, DRBD is an excellent tool and very feature-rich.

First of all, I can’t recommend the DRBD User Guide enough. It really lays out the features and usage not just of DRBD but also some common applications you would use alongside like LVM for storage management and Pacemaker and Heartbeat (and others) for clustering.

What DRBD is going to do is basically copy writes to a block device over the network to a replica device – this storage set is called a “resource”. Generally, you will expect to have two nodes for each resource. During normal operation, you will have one “Primary” node and one “Secondary” node for each resource which logically indicates that one node is writing changes to the resource while the other is making a copy. DRBD is generally very slick in handling replication and the status of the nodes. First of all, when you configure the resource, you specify an IP address for the replication target and generally you are going to want this to be a separate network interface from your general data plane – for example a cross-over cable for point-to-point connection between the two nodes. If the replication path goes down, DRBD is basically going to mark at what point in time it happened and then keep track of which blocks changed since that point so when the path comes back up, it has a list of which blocks need to be transferred instead of having to resync the whole device. That’s another thing – it does the whole device sync for you too when you create the device. And also, you get basically the same behaviour if your secondary node tanks, or if both nodes tank for that matter, or even the primary node.

Unless both nodes end up in a “primary” state during some overlapping time. So if you automatically bring up the secondary node in case of a primary failure with Pacemaker, for example, but the issue was a path failure and not a node failure, then both nodes may end up in “primary” state. Since DRBD is tracking when communication is disrupted, it will detect this problem – a “split brain”. You get several options for manual resolution (I think automatic as well) including taking the changes of one node or the other, the node with the “most” changes, the node with the “least” changes, the oldest primary, the youngest primary… You may still be stuck losing some data – but you can keep both nodes in split brain and consolidate externally (e.g. if you have critical data like financial data where you can never drop a transaction).

DRBD supports three replication “protocols” called, intuitively, A, B, and C. “A” is asynchronous so writes to local storage device unblock after the local device finishes writing. “B” is “semi-synchronous” which unblocks after the data has reached the peer. And “C” which is “synchronous” so the write operation is only complete once the data is written to both devices. I was finding that “A” and “B” got me similar speeds and “C” was slower – but this is not very rigorous testing and my replication link was 100Mbps through a shared data plane.

One of the things about any of these replication options compared to rsync is that they are going to generally be much nicer on your memory. I find that when rsync scrapes the file system, this effectively nukes the OS’s disk cache such that after rsync runs, users may notice it takes a while to “warm up” again. But, replication is not a backup – if a virus eats your files on your primary node, it will eat them on the secondary node synchronously or asynchronously – your choice.

If you are using LVM (and you should be, I’ve posted about LVM before, so have others), you’ll wonder whether you layer DRBD on top of LVM or vise-versa. As Chef would say: Use DRBD on top of your LVs. Dramatic over-simplification aside, it does depend on what you are doing. If you are using LVM to carve up a pool of storage for example for virtualization and then want the storage layer to replicate your VMs, it may make more sense to create your DRBD volume from physical storage, then it will replicate the whole LVM structure to your replica node. But there’s complications like ensuring LVM will even look at DRBD devices for PVs and managing size changes, etc. There’s a time and a place for everything, and that’s college.

Um, what else is awesome about DRBD? Offline initialization, “truck based replication” (a.k.a. sneakernet), replicate the node locally, ship it to the remote site, turn-up from there. DRBD Proxy (paid feature) for when you need to buffer replication for slow or unreliable network links. Dual-primary (for use with something like GFS) operation. 3 node operation by layering DRBD on top of DRBD.

Yeah, it’s cool. It’s Free and free. You can get it stock with Fedora and CentOS (probably Ubuntu and others, but haven’t tried it yet).

And one last thing – you cannot mount a resource that is “Secondary”. So if you are getting crazy error messages that you can neither mount nor even fsck your file system, it’s probably in Secondary – don’t bang your head against the wall, just do “drbdadm primary ”. Is clear?

Great article on DRBD