Enterprise Cloud infrastructure provides storage API essential

It is easy to pick up problems with older storage products, especially when public and private cloud deployments are integrated. However, what is needed when implementing the cloud framework is worth discussing, because storage is deployed in a way that is distinct from the traditional pattern of storage operations. In this article, we'll explore why traditional storage management needs to change and how it affects how the hardware is used. This raises a discussion about APIs, and they are essential for efficient cloud deployment.

Traditional mode

Traditional configuration process

Over the past 10 years or so, the traditional pattern of storage management includes multiple storage administrators, using GUI,CLI and/or scripts to address the storage needs of business users. This process is highly artificial, with many associations between the requirements, storage administrators, and other intermediaries such as billing, change control, capacity management, and job scheduling. This makes the entire process very personnel intensive and has no unintended extension of the delivery time. Many end users also experience the requirement that their specific requirements are told they can only have "ready-made" things-such as a standard LUN size and storage with a specific raid protection. The reason for this is obvious: first, the configuration of a large array depends on the planned and determined design, which is typically established during hardware installation. Once identified and put into use, it can no longer change (or at least change without significant impact and cost). Second, this is also a good way to reduce the need to a smaller subset, so that the configuration process is easier. There are also rigid configurations, and many traditional arrays regard the creation and configuration of LUNs as a rare task. Many requests are packaged and executed in bulk, so it is certainly not easy to respond to concurrent requests. Although some configuration processes can be automated by using the CLI and scripts, this does not address the actual need to create a demand-only model.

World

API configuration Process

When we scale to larger it deployments, especially in the context of a service based or "cloud" configuration, the idea of a lot of human intervention in the configuration process will not work. We need to move on to a "store by demand" model where an external agent (user or business process software) can be stored as an entry request and can view the processing of requests in real time or at least a few minutes or hours. This operation is provided only when the hardware is designed to be done as intended. Prior to this, the storage administrator participates in each configuration request, and those requests are processed within a configuration framework defined by an administrator or storage architect.

Framework

What do we mean by the framework? It is the creation of a set of parameters when the allocation occurs. This may include:

LUN Size

Elasticity/Usability

Performance

Security certificate

Snapshot policy

Capacity on Demand LUN

Architects to select specific hardware components that meet the requirements.

There are some limitations to use:

Maximum number of concurrent requests

Maximum number of configuration requests per hour

Ability to pause or deny array configuration requests

Request by array capacity limit

Limit user requests by capacity guidelines

Setting up the framework also requires the ability to work autonomously; that is, accept, process, and tell the request without having to keep the session with the array. Once the request completes, the requester is notified by a callback mechanism or manually whether the request is complete. It is clear that the monitoring framework needs to be integrated to track hardware and performance issues.

Design API

The big question, of course, is whether the API can replace existing storage. The answer to the classic it tradition is "it depends." There is no doubt that the new storage array should not be released without the local API functionality. Then, having the API cater to the existing technology will depend on how flexible the existing configuration process is. It is possible to create an API to outsource and build automation at the middleware level. This is also the practice of storage automator such products as Iwave. However, adding these capabilities to existing storage products is very costly and still an imperfect solution.

Storage Architect's Perspective

With the development of new storage platforms, local API support is a necessity. The storage administrator simply deploys the infrastructure and connects it to a higher framework, and the configuration process is fully automated. Providers of this level of functionality will become the most attractive service providers-making the cost of capturing and managing storage as inexpensive as possible. We'll see a shift in storage management, and perhaps no more storage administrators.