Читать книгу VMware Software-Defined Storage - Martin Hosken - Страница 10

Gathering requirements and documenting driving factors is a key objective for you, the architect. Understanding the customer’s business objectives, challenges, and requirements should always be the first task you undertake, before any design can be produced. From this activity, you can translate the outcomes into design factors, requirements, constraints, risks, and assumptions, which are all critical to the success of the vSphere storage design.

Architects use many approaches and methodologies to provide customers with a meaningful design that meets their current and future needs. Figure 1.2 illustrates one such method, which provides an elastic sequence of activities that can typically 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 budget will depend on multiple factors. It might be too small a number, and you can think of it as a design constraint. In an ideal world, the design should focus only on system readiness, performance, and capacity, with an aim to provide a world-class solution with the future in mind, regardless of the cost. However, this is rarely the case; typically, the task of an architect is to take in all of the requirements and provide the best solution with the lowest conceivable budget. Even if, as the architect, you are not accountable for the financial aspects of the design, it’s typically useful to have an understanding of budgetary constraints and to be able to demonstrate value for money, as and when required.

Manageability

For this design factor, you should keep in mind KISS: keep it standardized and simple. Making a design unnecessarily complex has a serious impact on the manageability of the environment. Also, a design that is unnecessarily complex can easily contribute to failure, because the operational team might not understand the design, and making a change to one component can have implications on another. Instead, your aim should be to keep the design as simple as possible, while still meeting the business goals. The objective should be to keep the design easy to deploy, easy to administer and maintain for the operational teams, and easy to update and upgrade when the time comes.

Goals

The key goals for the design will be different for each project. However, in general, a good design is not unnecessarily complex, provides detailed documentation (which includes rationales for design decisions), balances the organization’s requirements with technical best practices, and involves key stakeholders and the customer’s subject matter experts in every aspect of the design, delivery, testing, and hand-over of the storage platform.

Security and Governance

Needless to say, in today’s world security is a key deliverable in every enterprise IT or cloud service provider project. On some of the projects involving government agencies and financial institutions that I’ve worked on almost every aspect of the design is governed by security considerations and requirements. This can have a significant impact on both operational considerations and budget.

Standards

An enterprise organization or cloud service provider typically has standards that must be met for every project. Hopefully, these standards include a clear methodology for identifying stakeholders, identifying the most relevant business drivers, and providing transparency and traceability for all decisions. Standards might also include a defined and repeatable approach to design, delivery, testing and verification, and hand-over to operational teams.

Performance

Like availability, performance is often governed by a service-level agreement. The design must meet the performance requirements set out by the customer. Performance is typically measured by achievable throughput, latency, I/O per second, or other defined metrics the customer deems appropriate. Storage performance is probably less understood than capacity or availability. However, in a virtualized infrastructure, not much has a greater impact on the overall performance of the environment than the storage platform.

Recoverability

Like availability and performance, recoverability is typically governed by a service-level agreement. The design should document how the infrastructure can be recovered from any kind of outage. Typically, two metrics are used to define recoverability: recovery time objective (RTO), which is the amount of time it takes to restore the service after the disruption began; and recovery point objective (RPO), which is the point in time at which data must be recovered to, after the disruption began.

Scalability

The design should be scalable – able to grow as the customer’s data requirements change and the storage platform is required to expand. As part of the project, it is important to determine the business growth plans for data capacity, and any future performance requirements. This information is typically provided as a percentage of growth per year, and the design should take these factors into account. Later we address a building-block approach to storage design, but for now, it’s of key importance that the customer is able to provide clear expectations on the growth of their environment, as this will almost certainly impact the design.

Capacity

The design’s capacity requirements can typically be achieved as a business grows or shrinks. Capacity is generally predictable and can be provisioned on demand, as it is typically a relatively easy procedure to add disks and/or enclosures to most storage arrays or hosts without experiencing downtime. As a result, capacity can be managed relatively easily, but it is still an important aspect of storage design.