Yes the SME backup will still be successful but the logs will not be truncated as they have yet been commited to all the DB copies yet. Brad
... View more
During the SME backup the process of log truncation is handled by Exchange. In the case where DAG replication is not working properly and logs are not being copied and played into passive database copies Exhcange will not truncate the log file until it has been played into all the necessary passive copies.
... View more
All the customer data we have seen alignes with what Rob has said. In a 2003/2007 environment we don't see over 10%. With that type of return it really doesn't buy you anything. As far as Exchange 2010 is concerned, Andrew is correct there is no more SIS, there are also some additional features that may possibly result in better numbers dedupe which may provide a much better return. Brad
... View more
Yes unfortunately there really isn't a magic guide as to what will yield what results. This tends to vary alot for different environment so there isn't really a best practice or guide table. Brad
... View more
The Averaged RPC latency is the measure of how long it takes to for a packet to be processed. Below is the description on the counter from Microsoft taken from the Exchange Server Analyzer tool. The RPC Averaged Latency performance counter records the average time, in milliseconds (ms), that it takes for the last 1024 packets to be processed. The latency represents how long it takes from the time the Store.exe process received the packet to the time it returned the packet. The RPC Averaged Latency performance counter does not include any network latency or any latency that is introduced by anything other than the Store.exe process. Although the RPC Averaged Latency performance counter data does not include network transit time, it does provide data about the shortest time period that client computers have waited for a response from the server. If the RPC Averaged Latency performance counter data is lower than 50 ms, the server can process the requests in a reasonable amount of time. If the counter stays greater than 50 ms for more than several seconds, this indicates that the server is having difficulty keeping up with the load. As a result, users may experience delays when accessing their e-mail. If average latency is greater than 100 ms, users will receive the following pop-up window from their Microsoft Office Outlook® client computers: "Retrieving data from Exchange Server." This is monitored from perfmon as part of the MSExchangeIS object. MSExchangeIS\RPC Averaged Latency Brad
... View more
You are absolutely correct, much of the Thin Provisioning question of whether or not the customer can handle it. Like I said in my earlier post the key to thin provisioning isn't the setup or the technology itself but monitoring. If the customer has monitors space for their applications as well as the ongoing rate of change for Snapshots then thin provisioning can be a great option. On the flip side of that coin, if the customer is the type that does not monitor, then thin provision is probably not the best option. Also, let's not get Thin Provisioning and 2x+delta confused, as they are two different things. Thin provisioning is basically presenting more storage to the server than is actually physically present on the backing storage. When the environment begins to approach the point where additional capacity is required then more storage must be added. 2x+delta is just a method of calculating the total volume space is needed. 2x+delta is still a bunch of extra space. Now if the customer has no real idea what any of the sizing information is... doesn't have mailbox limits, or doesn't really know what the average mailbox size is, and doesn't know how many snapshots they want to keep online. Then 2x+delta is probably the answer for them. But using that methodology for a customer that does know that information is probably just adding extra capacity to the volume. The next item on the list is dedupe. I wold completely agree, it's a popular item and everyone wants to dedupe their data. The only thing I would caution is that certain application data types lend themselves better to dedupe than others. For instance dedupe of SharePoint will usually yield better returns that dedupe of Exchange data. Brad
... View more
The basic rules for verification throttling are based more on disk latency. The trick is to figure out how long to configure the the verification to "sleep" to lower the latency to acceptable limits. The first step is to monitor the disk latency during verification. So you'll want to look at the Average Disk/Sec. Read and Average Disk/Sec Write counters. To be in line with Microsoft practices these need to be below 20ms. You will want to look at these counters for each LUN containing the DB's being verified. During the verification time if the latencies are above 20ms then the verification throttle can be adjusted in order to keep the latency within the acceptable limits. Brad
... View more
The replies above regarding LUN IDs are good points. But focusing from a pure iGroup perspective Rick is correct, I can't really think of any down sides to letting SnapDrive control this automatically unless you really need to manually control the iGroup names in your environment.
... View more
What is the current verification throughput and what are you trying to achieve from that perspective. Verification throttling will allow throttle the amount of I/O load the verification process places on an Exchange Server. So as far as to which way to adjust these settings depends primarily on the current load being placed on the server during verification and what you are targeting. Brad
... View more
The partner misconfigured error could be a couple of different thing. It could be something as simple as a configuration issue or it could also mean that the primary path between the host and the storage has failed. Is this something that happens only during verification or at other times as well such as during the SnapMirror process. Is this just something that is failing during the verification process? Sorry I couldn't provide more details, Brad
... View more
As far as the method used to collect and monitor performance trends I honestly think it comes down to whatever works best. The method your currently using works. The Exchange performance analyzer is another good way to get an insight as to performance. Systems center is another good way to get at the information. As far as just monitoring the performance monitoring averaged read and write latency and ensuring both are under 20ms with spikes no higher than 50ms is one of the key things. One of the other things I like to watch is the Averaged RPC latency. While this isn't completely disk related, it can be a good indicator of client side performance. This should be kept at under 50 ms. Once this starts to creep higher clients may notice connection issues. This impact can be seen expecially with clients in online mode.
... View more
You are correct, using the 2x+delta method and 100% Fractional reserve will definitely cause the amount of space needed to add up very quickly. I'll answer this question with respect to Exchange, but note that the methodology can be used for MOSS or SQL server as well. We have done a lot of work recently in regards to sizing and the 2x+delta methodology, especially with Exchange. The concept of volume sizing can be broken down into 2 different parts, the database volume and the transaction log volume. Just a note, the total LUN sizes required is used as a basis for volume sizing. NetApp recommends that when sizing Exchange volumes the Microsoft sizing spreadsheet for Exchange first be used in order to determine appropriate amount of space needed for each LUN. Total LUN Requirements are used as the basis for calculating volume space requirements. Once we have the basic LUN capacity requirements we can easily size each volume using the x+delta method which is much closer to the capacity needs. Transaction Log Volume Sizing Providing accurate sizing for transaction log volumes depends on the following factors. Total Transaction log LUN size = Total size of all transaction log LUNs that will be stored in one transaction log volume Snapshot copy space = Space consumed by transaction logs generated during a 24 hour period Online Backup Retention Duration = Number of day that backups are kept online. A day is measure by 24 hours Fault Tolerance Window =This is the number of days that backup failures can be tolerated before running out of Snapshot copy space. A typical value for this is 2 – 4. Transaction log volume sizing can be calculated using the following formula. Transaction Log Volume size = Total Transaction Log LUN size+ (snapshot copy space * Online Backup Retention Duration + Fault Tolerance Window) Database Volume Sizing Providing that an accurate change rate is known the following formula would be used in calculating total volume size. The formula below is based on 2 different key variables. To calculate the Exchange DB volume size a number of variable are used: Database LUN Size =The size the LUN used to store Exchange Mailbox or Public Folder Database Database daily change rate = The amount the Exchange Mailbox or Public Folder Database changes in a day expressed as a percentage value of the database size. Online Backup Retention Duration = Number of day that backups are kept online. A day is measure by 24 hours Fault Tolerance Window =This is the number of days that backup failures can be tolerated before running out of Snapshot copy space. A typical value for this is 2 – 4. Database volume size can be calculated using the following formula Database Volume Size = (Sum of the database LUN sizes that will share the database volume) + ((Fault Tolerance Window + Online Backup Retention Duration) * database daily change rate) Fractional Reserve Now that we've covered the basic volume sizing let's tackle the question of Fractional Reserve. Historically this has been set at 100% which essentially means you'll wind up with a lot of headroom in the volume. The preferred method is to set fractional reserve to 0% and use the auto delete. So what exactly does auto delete do? When a low volume threshold is triggered, auto delete will delete snapshots to reclaim space until the target free space percentage is hit. I often get the question "why is it recommended to use auto delete? Why can't I just use auto grow to grow my volume when the low space threshold is hit?" To answer the question, you can use auto grow but in order to guarantee space auto delete must be used as well. The reason for this is that there may be cases when auto grow can no longer grow a volume, such as a low space condition in the aggregate. That's why the recommendation is to use auto delete. I will reply more in depth as to the recommended settings when using fractional reserve to 0 in a later post. Thin Provisioning Thin provisioning in and Exchange or other application environment is completely fine. The trick to ensuring that you don't run into capacity problems which could cause the application to go offline is monitoring. If you are going to thin provision storage you need to make sure the you monitor volume capacity religiously. In environments where there is no dedicated storage admin or volume space is not monitored I typically recommend not to thin provision. I hope this helps! Brad Garvey
... View more
