VMware Software-Defined Storage. Martin Hosken

fulfill all stages of the design process. However, many organizations have their own approach, which may dictate this process and mandate specific deliverables and project methodologies.

Figure 1.2 Example of a design sequence methodology

      Technical Assessment and Requirements Gathering

The first step toward any design engagement is discovery, and the process of gathering the requirements for the environment in which the vSphere-based storage will be deployed. Many practices are available for gathering requirements, with each having value in different customer scenarios. As the architect, you must use the best technique to gain a complete picture from various stakeholders. This may include one-to-one meetings with IT organizational leaders and sponsors, facilitated sessions or workshops with the team responsible for managing the storage operations, and review of existing documents. Table 1.1 lists key questions that you need to ask stakeholder and operational teams.

Table 1.1 Requirements gathering

      After all design factors and business drivers have been reviewed and analyzed, it is essential to take into account the integration of all components into the design, before beginning the qualification effort needed to sort through the available products and determine which solution will meet the customer’s objectives. The integration of all components within a design can take place only if factors such as data architecture, business drivers, application architecture, and technologies are put together.

      The overall aim of all the questions is to quantify the objectives and business goals. For instance, these objectives and goals might include the following:

      Performance User numbers and application demands: Does the organization wish to implement a storage environment capable of handling an increase in user numbers and application storage demands, without sacrificing end-user experience?

      Total Cost of Ownership Does the organization wish to provide separate business units with a storage environment that provides significant cost relief?

      Scalability Does the organization wish to ensure capability and sustainability of the storage infrastructure for business continuity and future growth?

      Management Does the organization wish to provide a solution that simplifies the management of storage resources, and therefore requires improved tools to support this new approach?

      Business Continuity and Disaster Recovery Does the organization wish to provide a solution that can facilitate high levels of availability, disaster avoidance, and quick and reliable recovery from incidents?

      In addition to focusing on these goals, you need to collect information relating to the existing infrastructure and any new technical requirements that might exist. These technical requirements will come about as a result of the business objectives and the current state analysis of the environment. However, these are likely to include the following:

      • Application classification

      • Physical and virtual network constraints

      • Host server options

      • Virtual machines and workload deployment methodology

      • Network-attached storage (NAS) systems

      • Storage area network (SAN) systems

      Understanding the customer’s business goals is critical, but what makes it such a challenge is that no two projects are ever the same. Whether it is different hardware, operating systems, maintenance levels, physical or virtual servers, or number of volumes, the new design must be validated for each component within each customer’s specific infrastructure. In addition, just as every environment is different, no two workloads are the same either. For instance, peak times can vary from site to site and from customer to customer. These individual differentiators must be validated one by one, in order to determine the configuration required to meet the customer’s design objectives.

      Establishing Storage Design Factors

      Establishing storage design factors is key to any architecture. However, as previously stated, the elements will vary from one engagement to another. Nevertheless, and this is important, the design should focus on the business drivers and design factors, and not the product features or latest technology specification from the customer’s preferred storage hardware vendor. A customer-preferred storage device could well be the best product ever, but may not align with the customer use cases, regardless of what they’re being told by their supplier. Therefore, creating an architecture that focuses on the hardware specification and not the business goals is likely to introduce significant risks and ultimately fail as a design.

Although the business drivers and design factors for each customer will be different, with all having their own priorities and goals that need to be factored into the design, you likely will see many common design qualities, illustrated in Figure 1.3, time and time again.

Figure 1.3 Storage architecture business drivers and design factors

      Availability

      The availability of the storage infrastructure is typically dictated by a service-level agreement (SLA) of some sort, and is often represented as a percentage of possible uptime (such as four nines, 99.99 percent). Availability is achieved through techniques such as redundant hardware, RAID technologies, array mirroring, or eliminating single points of failure. Additionally, high levels of availability can be provided by using technologies such as storage replication, vSphere anti-affinity rules, or Virtual SAN Stretched Clusters. An available design is reliable and implements multiple mechanisms to restore services within the IT organization’s agreed-upon service-level agreement.

      Compliance

      Compliance means conforming to a specification, policy, standard, or law. Regulatory compliance is now a part of everyday life for an information technology architect. Having a strong understanding of the requirements that the customers must comply with will help significantly in producing a design that meets the needs of the organization you’re working with. Compliance goals also differ for different countries. For instance, in the United States, architects may be familiar with the Sarbanes–Oxley Act of 2002 or the Health Insurance Portability and Accountability Act of 1996 (HIPAA). In addition, global compliance standards, such as the Payment Card Industry Data Security Standard (PCI DSS), cross geographical boundaries.

      Usability

      Usability is the ease of use and learnability of the day-to-day operations associated with the storage platform. As the architect, one of your tasks will be to ensure that the customer’s operational team or administrators are able to manage the environment after you leave and move on to the next project. This, of course, links into manageability, and you may be required to provide operational documentation, or partake in knowledge transfer and training as defined in the scope of work.

      Budget

      Unfortunately, few projects have unlimited budgets. Cost is always at the forefront of stakeholders’ minds, and, as the architect, you will probably find that justifying costs associated with the design will often come down to you. I can assure you from personal experience that CFOs and their representatives can be scary and love to ask difficult and challenging questions. (To be fair, all they are trying to do is justify costs, so let’s not be too hard on them.) Your goal is to meet the organization’s business needs, while remaining within budget. If this is not possible, you must be able to explain and justify the best course of action to the organization’s key stakeholders, who hold the purse strings.

      The