LUNs on a storage system represent the blobs of storage that are allocated to a server. A (VNX) storage admin creates a LUN on a RAID Group or Storage Pool and assigns it to a server. The server admin discovers this LUN, formats it, mounts it (or assigns a drive letter) and starts to use it. Storage 101. But there’s more to it than just carving out LUNs from a big pile of Terabytes. One important aspect is LUN ownership: which storage processor will process the I/O for that specific LUN?!
Anyone working in IT knows that there are usually enormous amounts of whitepapers available to help you install, configure and run a new system or software suite. The fun more than doubles when the whitepapers start conflicting themselves. But even when they’re crystal clear, sometimes you run into a different problem: budget! With all planning and designing done, sometimes the budget or the purchased equipment does not allow you to follow ALL best practices to the letter, or at least make it a bit more challenging. In this example there’s the need to span a storage pool across DAE 0_0.
Recently I ran into an environment with a couple of VNX5700 systems that were attached to the front-end SAN switches with only two ports per storage processor. The customer was complaining: performance was OK most of the time but at some times during the day the performance was noticeably lower. Analysis revealed that the back-end was coping well with the workload (30-50% load on the disks and storage processors). The front-end ports were a bit (over)loaded and spewing QFULL errors. Time to cable in some extra ports and to rebalance the existing hosts over the new storage paths!