Supporting Spectrum Virtualize

Hello friends. For the next few weeks (while I am in a dry spell for post ideas) I am going to do a series of posts that are frequently asked questions I get from some of my peer support agents as well as others I interact with day-to-day. For the first go-around we will discuss remote copy. Specifically, what exactly is a 1920 error? How do I identify the cause of the error and stop it from happening again? A 1920 error is a cluster error indicating that the software in the master cluster of a remote copy relationship has decided to kill remote copy for a particular relationship (and its associated consistency group) because the SLA of remote copy was violated as defined in the partnership settings. The first and probably most important thing to know is what that SLA is and how it is defined. For this, go ahead and run lspartnership against your remote copy partnership (or check partnership properties in gui... your call). If you run lspartnersip you will see something like this:

Hello friends. I know it has been a while but I am back now. I was having a conversation with someone on troubleshooting the performance of a SVC cluster and the question came up as to why isolated ports for inter-node are needed and exactly how many are needed - the answer to which I would like to share more broadly. Recall from the IBM Spectrum Virtualize Software Overview that there are many forwarding layers in the i/o stack. These forwarding layers are used to perform cache mirroring of all write i/o during various stages of i/o processing. Any delay in forwarding results in queuing of write i/o because the software enforces cache mirroring in order to both acknowledge the write completion to the host and to manipulate said data and destage it to the back-end. Failure to do this would result in data loss and/or corruption. This cache mirroring depends on the inter-node ports (also referred to as local node ports or intracluster ports). Any bottleneck to these ports by extens

Hello friends - better late than never. There has been a lot of excitement about using Data Reduction Pools (DRP). Today I would like to take a moment to provide a semi-brief explanation of what DRP is and how exactly it works. DRP is designed to take full advantage of various data reduction technologies. This is achieved by re-designing how data in pools are managed and maintained. Lets first discuss what makes DRP different than the "legacy" standard pools. DRP Volumes Journal Volume   The Journal volume works similar to a filesystem journal in that it can be used to recover the pool in disastrous scenarios such as a T3 Recovery.  This volume also only processes sequential writes, and is only read from to perform recovery actions. This volume is hidden to the user. Customer Data Volume The Customer Data Volume consumes ~98% of the pool capacity and stores all data that is written into the pool. All writes to this volume will be sequential 256K i/o reads out of