Cisco MDS 9000 and IBM FICON: Just Got Married Again

We know humans like to celebrate. The wedding date represents a significant one for many couples and there is a tradition to celebrate again, even if with less fanfare, upon reaching a specific amount of years together. Apparently originated from an ancient German tradition, there is also a symbolic name to represent how long ago the wedding occurred. For example, the golden wedding indicates 50 years of marriage.

Cisco MDS 9000 series and IBM mainframe FICON have not reached that level yet. The original wedding date was in 2004, and 2020 marks 16 years, assuming my math is not wrong. There is a name for this, despite not popularly used. It is called ivy wedding….but don’t ask me why.

IBM originally announced FICON channels for the S/390 system in May of 1998. Since then, FICON has evolved from 1 Gbit to the 16 Gbit FICON Express16S channels, announced in January 2015 in conjunction with the IBM Systems z13. Each generation of FICON channels offered increased performance and capacity. Initially, the FC-SB-2 Fibre Channel upper-level protocol (ULP) was used by FICON. As the name implies, a single byte (SB) link address was used to specify the switch port on the director, out of a range of 00-255. It supported key features like native FICON storage devices, channel-to-channel connections, FICON directors (or switches), and more. But it did not allow for switched paths over multiple directors. In 2003, with the introduction of a new and enhanced ULP, this limitation was removed. In fact, FC-SB-3 employs a dual byte address.

Funny enough, rather than changing the name from SB to DB, it was decided to change the version instead, increasing its number from 2 to 3. This was the beginning of cascaded FICON. Two directors per fabric, also known as single-hop cascading, became possible since then. Recently multi-hop cascading has been qualified and has opened up new deployment options. Fibre Channel Single-Byte-4 (FC-SB-4) standard followed in 2008 and accounted for a big step forward in terms of performance, by reducing FICON channel overhead with the introduction of the high-performance FICON for System Z (zHPF).

A few years later, FC-SB-5 was standardized and in 2020 work is still in progress for the FC-SB-6 standard and new improvements are expected. Meanwhile, new routing schemas have come along, specifically FICON Dynamic Routing (FIDR), creating an exchange-based routing model (OXID-based routing). Meanwhile, the mainframe gained enhanced monitoring capabilities for switching devices with a revamped version of the CUP protocol.

Just as the protocol and the topologies have evolved over time, the same is true for requirements, expectations, and underlying hardware products. Cisco MDS 9000 series has just completed the most stringent testing and validation exercise, successfully receiving its latest FICON certification letter and can be found on the IBM resource link page (registration is needed to access this website).

With software version, NX OS 8.4(2b), Cisco MDS 9710, MDS 9706, and MDS 9250i and their IBM c-type counterpart have renewed their approval for use within mainframe environments with the full feature set. It is a great achievement, putting Cisco MDS 9000 series at the center of customers’ preferences when it comes to both FICON and Fibre Channel switching. Specifically, the new certification adds support for:

◉ IBM Fiber Channel Endpoint Security

◉ CUP Diagnostics

◉ Support for z/OS health checker

◉ 16G and 32G ELW optics for extended reach on dark fiber

Continue reading

Top 10 Challenges Solved by SAN Analytics

Delivering high levels of performance for enterprise storage environments is a key objective for CIOs and CTOs, often measured in millions of Input/Output Operations Per Second (IOPS) and microsecond response times.

Production storage environments are extremely complicated, however, so that optimizing performance is akin to solving a multidimensional equation containing multiple variables that constantly interact with each other. Without visibility into those interactions, you’re left with best efforts for optimization. The likely consequence is neither an ability to extract maximum value from the storage investment nor the delivery of maximum performance to the business.

The solution? SAN analytics. IBM c-type SAN Analytics, is the industry’s first and only integrated-by-design architecture, provides deep visibility into SCSI and NVMe traffic at scale. Below, I’ve listed top 10 challenges that can be solved with IBM c-type SAN Analytics.

#1: Find the slowest storage and host ports in the entire network fabric.

Proactively identify storage and host devices (or ports) causing bottlenecks and affecting application performance. Storage admins often look for ports in the path of slow IO transactions, defined as longer IO or Exchange Completion Time (ECT), which is the time to complete read or write transactions.

#2: Identify the busiest storage and host ports in the entire network fabric.

You can monitor the busy devices and proactively plan capacity expansion to address the high-usage ports before they affect application performance. Note, knowing a busy device solves a different problem than knowing a slow device.

#3: Discover if poor application performance is due to storage access issues.

If ECT increases, slow storage access may be the cause for application performance degradation. If ECT does not change, you can safely rule out storage access issues and focus your troubleshooting on other infrastructure components.

#4: Determine the cause of storage access issues: storage array, SAN, or host.

If you determine that application performance issues are due to slow storage access, IBM c-type SAN Analytics can pinpoint where this slowdown occurs: within the storage array, in the host, or due to congestion (or slow drain) within the SAN.

#5: Verify multipath (MPIO).

To help optimize storage usage and avoid unplanned downtime, end-to-end paths between a host and storage are proactively monitored to prevent potential multipath issues. IBM c-type SAN Analytics can help you detect if all the paths are not active, or if their utilization is not uniform.

#6: Establish higher levels of visibility between Cisco® UCS Servers and vHBA traffic.

Expedite issue remediation and improve SLAs by getting end-to-end visibility between blade servers, SAN, and storage LUNs. IBM c-type SAN Analytics provides visibility into the vHBA traffic of the Cisco UCS servers by inspecting the frame headers that carry FCID of the server vHBA. Finally, DCNM SAN Insights correlates the initiator FCID to the WWPN of the server vHBA and the host enclosure.

#7: Stop the guesswork by implementing a data-driven storage vMotion.

Use the throughput, IOPS, and other information from IBM c-type SAN Analytics to optimize an application’s underlying infrastructure and make informed, data-driven decisions on moving storage-hungry VMs to lesser-used physical hosts or paths. This helps improve SLAs while reducing overall infrastructure costs.

#8: Verify and optimize the usage of storage array ports.

Confirm uniform usage and obtain detailed metrics at a LUN level to help make informed corrective actions. For example, if one port of a storage array is 70% utilized, while another port is only 30% utilized, you can move the LUN association to better balance the load.

#9: Enable change management and verification.

Hardware and software changes are ongoing in data centers (e.g., replacing faulty SFPs and cables, upgrading HBAs, performing software upgrades, and applying patches). Proper verification of changes can be challenging, due to a lack of end-to-end visibility. End-to-end monitoring via DCNM SAN Insights, run both before and after a change, can be used to prevent unplanned downtime, increasing customer satisfaction.

#10: Obtain automatic baseline and deviations.

Use advanced analytics, end-to-end correlations, and long-term trending to help make operations more proactive and productive. One of the biggest challenges facing storage admins is understanding the difference between good and good enough. As an example, just knowing the absolute value of ECT is of little help. Instead, you can use DCNM SAN Insights to learn the ECT of an IO flow, establish baselines, and calculate deviations automatically from the baseline.

Continue reading

Cisco and IBM: Partnering for Better Security

Considering the spate of cyber threats faced by customers, the need to more easily prioritize these threats, understand the scope and veracity of the attacks, and subsequently automate the responses, has never been more critical. While many security vendors exist to address some challenges, no single technology or vendor provides the complete security customers require. Therefore, providing this extended protection often requires a collaborative ecosystem of security vendors.

Continue reading