How to Reduce IBM Storage Costs

VMWare is a powerful software tool that can empower your IT staff to build a much more flexible and resilient environment for business applications. There are several benefits to utilizing VMWare with your SAN, NAS or iSCSI storage infrastructure.

• Availability - Shared data storage systems on redundant LAN or SAN Fibre Channel fabrics provide the ability for users to use tools such as VMWare VMotion and Site Recovery Manager to move, recover and monitor VMs with limited to zero system downtime
• Redundancy - Extend multi-pathing to all virtual machines, as well as extend failure resistance
• Performance - Makes load balancing and high availability more affordable by eliminating dedicated standby hardware
• Disaster Recovery - Disaster Recovery capabilities are enhanced when bare metal restore limitations are removed due to the VMWare hypervisor

While there are multiple benefits of shared storage for VMWare, you need to determine when your storage is configured correctly.

Properly planning the necessary storage capacity for an optimized VMWare environment requires proper planning and continuous performance tuning. The ultimate goal of performance optimization is finding and eliminating all possible roadblocks that reduce the full utilization of the Core Four resources (CPU, Network, Memory, and Storage). Here, we will discuss eliminating roadblocks for storage.

Storage Selection

When determining the best place in your storage infrastructure to deploy your VMWare environment, selecting the proper storage array or configuration is one of the most important factors. There is always the obvious trade-off between cost and performance and storage should divided into tiers depending on a number of factors. In the end, every application should be supported on the tier best suited for the business with a balance of cost in mind.

Tier 1 – Offers maximum performance and availability. This tier may utilize built-in snapshots to facilitate point-in-time restorations and supports replication, full storage processor redundancy, and Fibre Channel, SAS or SSD drive technology. Smaller, faster disk will improve performance here. This is a higher cost per spindle tier.

Tier 2 – Offers mid-range performance, less availability than high-tier storage, limited storage processor redundancy, and perhaps slower, larger Fibre Channel drives.

Tier 3—Offers limited performance and little storage redundancy. This tier should be built on high capacity, lower performance SATA drives.

NOTE: Not all VMWare applications or environments need to be in Tier 1., if certain elements call for Tier 2 or Tier 3 storage (such as redundancy or snapshots) there may be alternative methods for delivery, which include but are not limited to:

• Repurposing / Retrofitting a legacy storage platform
• Utilizing 10K 146 or 300GB fibre channel drives in leui of SATA drives
• Swapping SATA for fibre channel drives
• De-installed brand named storage arrays and storage expansion upgrades

If high-performance storage is needed and a budget isn’t available, Reliant Technology can often quickly provide 2-3 solutions to help improve performance without breaking the budget Talk to us now to find out more.

Disk Drives: Fibre vs. Sata vs. SSD vs. SAS

Assessing the correct tier for various applications is a critical step that cannot be skipped. When determining which application to run on high-performance disks and which ones to save for SATA-based tiers, it may help to ask yourself a few questions first.

• How critical is the VMWare environment to your business?
• What are the application-specific performance and availability requirements?
• What are the applications’ point-in-time (PiT) restoration requirements?
• What kind of backup requirements does this application have?
• Do I need to replicate this application’s data?

Many of our customers often find themselves deploying SATA technology for VMWare infrastructure, only to find themselves resource constrained with 6 months. When considering the type of disk drive to deploy, consider the long term requirements for the environment.

Properly Configuring the Storage Array

Storage array design will require storage managers to map the defined storage requirements to the resources of the storage array using these guidelines:

• Each RAID group provides a specific tiers of I/O performance, redundancy, and capacity. LUNs assigned to particular RAID groups should be based on these requirements. For example, high performance applications may be assigned to LUNS with RAID 10 configurations to increase I/O and spindle count
• Don’t skimp: If a particular RAID group is unable to ensure the required I/O performance, capacity, and proper response times, you must define an additional RAID group for the next set of LUNs. It is imperative that you supply sufficient RAID-group resources for each set of LUNs.
• The storage arrays must distribute the RAID groups across all back-end and internal channels and access paths. This ensures load balancing of all I/O requests to meet specific performance requirements of I/O operations per second and response times.

Peak Period Activity

It is important to base the design of the SAN around peak-period active and consider the nature of the I/O within those peak periods of time. You may find that additional storage resources and capacity are required to handle sudden spikes.

For example, a peak period may occur during batch processing or during morning usage spikes when end-users are coming online. This might be characterized by several peaking I/O sessions requiring twice to three times the average for the entire peak period. Without additional storage resources to handle peak activity, I/O demands will exceed the capacity of a storage array and may result in delayed response times.

Special Requirements for High Availability

Production systems need to be designed to eliminate all single points of failure. Make sure that redundancy is built into the storage design at all levels of the virtualized platform. Make sure that you build in additional switches, HBAs and HBA channels, and storage processors that create effective and redundant access paths to your data.

This can be done in a number of ways:

• Redundant Storage Components – Redundant SAN hardware such as HBAS, switches and directors and access ports are necessary for full redundancy. In certain cases, a redundant storage array may be part of the design
• Redundant I/O Paths —Paths from the host or server to the storage array need to be redundant and switchable if a port, device, or cable failure should occur
• Mirroring —In order to protection against failure of an entire LUN, mirroring can be implemented. Mirroring designates a second LUN designed to capture all write operations to the primary LUN. LUN mirroring can be either be implemented at the SAN switch, server, or storage array level



Planning for Disaster Recovery

In the event of a disaster scenario or site failure, it may be required to recover the failed applications and virtual machine data from a remote site. A storage array must allow access to the data from an alternate server in order to begin the data recovery process. VMWare, as well as VMWare Site Recovery Manager (SRM), makes this process easier as you do not have to reinstall the OS on a separate physical machine. Administrators can restore the virtual machine image and continue working from that point on.

Performance Tuning: What to Watch

If you have VMWare capacity planning tools or performance monitoring capabilities, here are a few performance metrics to watch on your storage array:

• I/O Reads
• I/O Writes
• Disk Write Queue Length
• Disk Read Queue Length
• Average Disk Sector Transfer Time
• I/O Read Bytes
• I/O Write Bytes



Improving Performance

When looking at improving performance for virutal machines and your VMWare environment, there are several ways to increase speed.

• First, ensure the LUN has enough capacity and the disk utilization isn’t too high. You might begin to experience degradation at high levels of utilization of volumes and devices (80-90%).
• Second, don’t just examine adding capacity as a way to improve performance—also consider adding more disk drives. For multi-threaded and I/O intensive applications, more disks often equates to improved performance. Applications that create or experience random read/write type of workloads usually required a number of disks to scale.
• Finally, RAID 10 can offer about 50% greater throughput than RAID 5 for random write-intensive environments.



Overcoming Budget Limitations

Often, increasing spindle count in order to improve performance can be expensive. In order to meet the I/O requirements and set proper RAID levels, creative methods must be employed in order to beat the cost/performance trade-off. Reliant Technology helps customers accomplish this through several different means.

• Utilizing Used Disk: Leveraging both new and used disk drives can reduce the cost of upgrading your storage environment by as much as 60%, allowing you to increase spindle count, create redundancy, or stand up a second array in order to support high availability applications
• Repurposing Legacy Equipment: Reliant Technology provides hardware, upgrades, and maintenance for legacy EMC, IBM, NetApp, and Hitachi storage systems enabling customers to upgrade and repurpose legacy equipment in order to create redundancy for Tier 1, 2 or 3 applications, support development and test environments, or afford extra backup capacity for faster point-in-time restores.
• Trade-In/Trade-Up: Find new life in in old equipment, and find new ways to meet your performance and capacity requirements.. Upgrade the storage area network, add larger faster disk drives or trade in your 2Gbps storage array for a 4Gbps or 8Gbps model.



Curious? Call Reliant Technology

Every environment is unique. Depending on your environment, there may be several potential ways we can help you reduce storage costs and improve performance in your data center.. In 10-20 minutes you engage a storage consultantand discuss your storage strategy and potentially save thousands in the process. Call 877.227.0828 or submit a quote to see how we can help you today.

REQUEST A QUOTE

To schedule an appointment with a storage consultant, email us or call us at 877.227.0828.

• BACK TO TOP

ORACLE Databases: Maintaining Performance



ORACLE is not a one-person job, as the database interfaces with hundreds of features and components. Data architects, database administrators (DBAs), storage managers, and a host of other business personnel must work coordinate in order to properly configure storage for ORACLE and properly tune the storage for optimal performance. We’ve included a few a few tips in order to simplify system configuration and performance tuning on your storage system.

Configuring the Big Four

There are four major hardware components to consider when building or fine-tuning an Oracle hardware infrastructure. Architects must ensure a balanced design, as the whole system is only as strong as the weakest link

• CPU
• Memory
• Data Storage
• Network

Although often an improvement in one or many of the above components may produce an improvement in performance, there are limits to that improvement depending on which variable may be creating a performance constraint.

Carefully identifying the problem component will make it easier and more cost-effective to alleviate any performance constraints that may be occurring. Any performance increases that result from adding hardware should be considered short-term relief, as increased application use is likely to cause the same problems in the near future.

[Talk with a storage expert] to determine what system is likely to scale most effectively for your environment when sizing or deploying a new system to support your Oracle databases.

Symptoms and Problems

• Slow Physical I/O – This results when disks have been configured improperly or too few resources have been allocated to support the database.
• Excessive CPU Usage – Excessive CPU usage means there is little to no idle CPU on the storage system. This can occur when a system has not been sized adequately due to inability of the CPU to scale and meet demand.
• Outages – This can occur when proper redundancy has not been built into the system in order to account for failures

Often, the symptoms are indication of an underlying problem in the hardware, poorly configured solutions, or untuned SQL statements.

Hardware and I/O Considerations

I/O performance is a key component when designing Oracle systems. When I/O workloads are especially intensive, the underlying I/O or storage system should be designed to meet these requirements. Under-sizing a solution can result in lost time and wasted resources for your business. These five guidelines can help you ensure that your system is properly built to support your databases for the entire life-cycle of the application.

1. Configure I/O for Bandwidth Before Capacity

Storage configurations should be assembled based on I/O bandwidth, and not only on their overall storage capacity. The capacity of each disk drive is growing much faster than their I/O throughput rates, creating a scenario where a small number of disks can hold a large data volume. However, these disks cannot handle the throughput of smaller disks. For example, spreading data over multiple 146GB or 73GB drives will result in better performance than a single 600GB disk.

2. Stripe as “Far and Wide” As Possible

Oracle recommends utilizing multiple disks and channels across database objects. This can be accomplished by striping datafiles of the Oracle databases bring deployed.

3. Use Redundancy

Disk redundancy is a requirement to protect against hardware failure. A key consideration is that often a balance must be struck between redundancy and performance. RAID 5 may be less expensive than RAID 10, however it may not perform as well. If cost constraints are an issue, a [Reliant storage consultant] can help you reduce the cost of the solution and still meet your needed performance levels.

4. Test The System Before Building A Database

Examine I/O and tune the system before the database is created. Once the file is created, reconfiguring the files becomes much more difficult. Greater collaboration across system resources makes this a troubling effort. It is important to remember that I/O bandwidth should be tested to validate that expected I/O levels are being achieved.

5. Plan for Growth

It is imperative to plan for future growth of an Oracle database. The key is to be able to grow and not compromise I/O bandwidth. Not properly planning for growth will eventually cause over-utilization of resources and performance problems.

Note: You cannot simply add disks to an existing system and add a new database table across new disks. Properly sizing the disk system the first time prevents complex upgrades and migration in order to grow an I/O system in the array.

If you have additional questions about upgrading an existing system or sizing an Oracle database, calling a Reliant storage consultant can save hundreds of hours and thousands of dollars (not to mention endless headaches and business risks).

Bottleneck Elimination

The purpose of tuning is to reduce resource consumption or reduce time for an operation to be completed. In general, performance problems result when a resource is over-used. This created a bottleneck in the system. Contention is a symptom that can often be fixed by making the changes below:

• Changes in the way the application is being used
• Changes in your Oracle database
• Changes in hardware configurations



Get It Right The First Time

Consider these requirements when designing a storage system and SAN to support your Oracle databases:

• Storage – Minimum disk capacity and spindle count. Remember that more spindles yields better performance.
• Availability – Is this a 24/7 system or will it only be utilized during business hours? 24/7 utilization requires proper engineering that can handle maintenance with no outages.
• Performance - I/O throughput and application response times will determine the necessary configuration

Need more information, or want to talk to an expert?

REQUEST A QUOTE

To schedule an appointment with a storage consultant, email us or call us at 877.227.0828.

• BACK TO TOP

Microsoft Exchange: SAN Best Practices



Deploying or utilizing a storage area network (SAN) for Microsoft Exchange requires careful hardware planning.Whether you are deploying Exchange in a Storage Area Network in order to consolidate your storage into a single platform, improve backup processes, or allow scalable growth to reduce expenses, migrating Exchange to a storage area network (SAN) is an essential part of planning the future of your infrastructure. Poor storage and infrastructure planning will result in poor performance and create additional headaches for end-users.

A modular or enterprise storage array typically has several advantages such as mirroring, replication, snapshots,disk LUN cloning and thin provisioning. These allow administrators to quickly set up test or lab environments and utilize space-efficient copies to test backups, upgrades, and Microsoft service packs.

However, as utilization of dedicated disks increases, performance can suffer and costs can spiral out of control when it comes time to handle capacity growth and accumulation of snapshots. The key is properly planning on the front end of your implementation to avoid these problems before they arise and man-hours lost to troubleshooting the issue.

Examine peak data usage

Hot spots in the SAN can create problems for all applications that also utilize storage on the system. If a single server makes excessive demands on that LUN, the performance of other servers will suffer. Examine peak data usage throughout the day and makes sure spikes and usage don’t compromise other systems.

RAID configuration

Although RAID 5 is more cost-effective, utilizing RAID 10 may yield better performance for Exchange environments that suffer from heavy I/O workloads.

Rapid Storage Growth

Users of Exchange environments often use their email as a filing cabinet filled with images, video, and other storage intensive files. As users have adopted email to manage their knowledge, over-utilization may begin to overwhelm the storage array.

Archiving solutions exist to house WORM and non-WORM data. Often an older storage array can be repurposed or retrofitted to be an archive target for Exchange.

Reach Out

You may know exactly what you want, and if so – that’s great. The storage consultants at Reliant Technology can offer you experienced advice on alternative ways to upgrade your system. Allow us to help you walk through these considerations and the many others necessary to properly upgrade your system , and we’ll show you way to do so - without breaking the bank.

Need more information, or want to talk to an expert?

REQUEST A QUOTE

To schedule an appointment with a storage consultant, email us or call us at 877.227.0828.

• BACK TO TOP

SQL Server: Advanced Protection



Protecting you SQL databases can mean saving thousands for your company in terms of ensuring productivity, meeting regulation requirements, and preventing downtime and data loss. Here are a few tips and tricks to ensure that your SQL databases are deployed correctly and available when the data is needed most.

In addition to the data itself, a SQL server includes the transaction log as well as the system databases. Both must be carefully protected if the application is going to be smoothly restored.

Watch Your Workloads Around Backup Windows

SQL backups can be performed while users are actively querying the database and transactions are being processed. SQL backups utilize a lot of system resources, especially I/O, so it’s best to perform intensive, full backups when the system is experiencing light load times.

Shorten Data Backups

If overall performance is suffering due to long backup windows, several measures can be taken to reduce the time that the system is performing a backup. One way to shorten is to backup to disk. If you’re backing up to disk before offloading to another backup system, take care to not backup to the same disk that is used to store the database or transaction.

Copying the database to a separate array can prevent I/O overload as well as ensure the database is available in the event of a primary system failure.

Use Different Backup Methods

SQL server offers different backup methods—full, differential, and transaction backups. There are built into the SQL server. Choosing the back-up method depends largely on your environment. Specifically, it depends on how large the database it is and how critical the database is to your business. Full backups can weigh down your servers and storage systems, so plan carefully how often you need to perform a full backup versus differential or transactional backups. Small databases that are not too large and change infrequently can be backed up only daily or weekly. Transactional databases that are mission critical should be backup up as often as possible.

Backup Transaction Logs Frequently

Next to the database, transaction logs are the most important data in a SQL server database. The log covers activity and can be used to perform PiT (point-in-time) restorations.

Remember: the transactional backup only backs up to the last transactional backup, so a full restore may mean performing a series of transactional backups in order to fully resort the database.

The transactional log should be performed every ten minutes for extremely active databases, and at least several times a day.

Backing Up SQL System Databases

The system databases are the other vital component of a SQL server application, including both msdb and master. There contain essential data such as system configuration and are necessary in the event of a complete restore. However, the system databases change less frequently and should be backed up at least weekly, or daily if it is a particularly active database.

One of the greatest factors that affects performance and protection of the Microsoft SQL server is the I/O of the disk subsystem.

Backups and Storage Growth

Multiple backups can create significant storage costs as full, differential, and transactional backups are performed for active SQL systems on a regular basis. Here are a few ways to control costs, and ensure the data is properly backed up.

• Offload backups to a separate, low-cost storage array. This practice ensures high-performance, high-cost disk is freed up for active databases.
• Planning for growth up-front can prevent expensive, last minutes storage purchases. When purchasing a storage array from Reliant Technology, your storage consultant will help you properly forecast your database growth and ensure you have enough low-cost, high-capacity disk to properly protect system and transactional logs for your databases.



Always Place Log Files on RAID 1+0 (or RAID 1) Disks

Placing databases and log files on RAID 10 can drastically improve performance and offer better protection from hardware failure. With better write performance, your system will avoid corruption and errors.

Note: In general RAID 1+0 will provide better throughput for write-intensive applications. The amount of performance gained will vary based on the HW vendor’s RAID implementations. Most common alternative to RAID 1+0 is RAID 5. Generally, RAID 1+0 provides better write performance than any other RAID level providing data protection, including RAID 5.

Need more information, or want to talk to an expert? Reliant storage consultants and engineers can help you determine how to get the best performance for your upcoming and existing SQL projects.

REQUEST A QUOTE

To schedule an appointment with a storage consultant, email us or call us at 877.227.0828.

• BACK TO TOP