Archives for March 2012

Mar
07

VDI-IOmark – VDI Storage Benchmarking For People With A Schedule

Translating Max IOPS into how many users you can fit onto a storage array(s) can be a pretty complicated question to ask of someone. Workloads are random between users, different blocks sizes are hitting the storage, AV is getting in the way and the list goes on and on. 20 IOPS per user is big joke in the VDI space. While 20 IOPS may represent the average, the deviation from that number can be astonishing. I encourage you watch Applied Math for VDI Design: A Statistical Approach to Designing VDI Environments. The session was presented at BriFourm last year and now is free. If you watch the video, you will see and understand what you need to be planning for.

VDI-IOmark from Evaluator Group is a tool that can tests your storage subsystem with realistic workloads. IOmeter can only give you simulated IO and not all the crazy behaviors of actual workload. VDI-IOmark uses workload replay from previous work captured from VMware RAWC implementation(View Planner). VDI-IOmark has 64 unique replays. The workloads range from 5 IOPS -20 IOPS on average but have peaks over 100. Microsoft Office(Excel, Powerpoint and Outlook), Internet Explorer, 7zip and Windows Media Player were all used to creat the replay. Boot and steady were also included in the replay. The tests are not dependent on your server platform, switching fabric or storage protocol so that’s a big thumbs up but it doesn need to run on .

The great thing about VDI-IO mark it that requires less the time to configure than building out a full environment. This is great if want to repurpose some old storage and test it our prior too or if you’re a consultant, you can do apple to apple comparisons between different vendors. Also since is each replay file contains 8 workloads test you can test your storage subsystem will less server hardware, you don’t need all the RAM it would normally take in a traditional LoginVSI or View Planner test. It’s always hard to get more money for test gear but people always want to know what the expensive box can do in the datacenter.
[Read more…]

Mar
04

McAfee VirusScan running on NetApp – How does it work?

Awhile ago I wrote a post on On-board antivirus for NetApp filers. I thought this was an interesting play for user profiles and your ThinApp repository The solution is a integrated approach to partnering with McAfee and you must be running at least Data ONTAP 8.1.

I was curious on how it actually worked and even more curious to see the impact of it running.

How and When a NetApp storage system determines to scan a File

1. Technically, the NetApp storage system will scan on:

Open

Rename

Close (if the file was modified)

2. The NetApp storage system will scan a file based on the file extensions set by the NetApp storage system’s administrator.

3. The NetApp storage system scans a file when the file is opened.

4. The NetApp storage system scans when a file is renamed to a file name that has one of the designated file extensions.

5. The NetApp storage system scans a file when a file is closed after being modified. The NetApp storage system does not scan a file after each write, but only when a modified file is closed.

6. Newly created files are not scanned on create, but only after data has been written to them and closed.

7. The NetApp storage system does not scan a file when the file is accessed from the vscan server itself.

8. If multiple applications access the same file simultaneously, they will all share the same scan results on the first application’s virus scan. For example, if application-1 requests to open a file and triggers a scan for viruses, the scan is launched. If application-2 tries to open the same file, the storage system will not launch a second scan, but instead queues up application-2 to wait for the already-active scan to complete. When the scan completes, both requests then continue being processed by the NetApp storage system.

The below is taken from http://media.netapp.com/documents/tr-3970.pdf

MCAFEE VSE ON-BOARD FOR NETAPP ARCHITECTURE

The VSE On-board solution consists of hooks in the data path to delay file operations and generate scan requests, and a user-mode application that mediates scan and management requests with a third-party
scanning engine. The main components of this architecture are:

AV filter. When a file is accessed by using the network protocols, the AV filter first decides whether or not the file needs to be scanned. This predecision is based on information like file extension, the share through which the request is coming, the protocol used, and so on. This information is passed to the AV on-access client.

AV on-access client. A module used by NetApp WAFL® (Write Anywhere File Layout) to manage virus scanning. Based on the predecision passed by the AV filter and the AV attributes of the inode, 5 McAfee VirusScan Enterprise On-board for Data ONTAP Operating in Cluster-Mode Deployment Guide the AV on-access client decides whether or not to scan the file. To scan a file, the AV client sends a request to the AV server.

AV server. Located in the user space, the AV server contains the third-party scan engine. Upon request of the AV on-access and on-demand clients, the AV server scans the file. A maximum of one AV server can be present per node.

AV on demand. Parses directories upon an administrator’s request and scans the files by sending a request to the AV server.

AV manager. Used to configure and monitor the antivirus feature and to manage the AV subsystems. On-access scanning is based on the AV policy defined for the volume. The AV policy can be assigned either to a v-server or to a volume. A volume inherits the AV policy from the v-server if there is no explicit policy assigned to it.

When I get my small filer, I hope I can do some testing and see the impact with the integrated AV on and off. I don’t see this as a replacement for running AV on your desktop but I would use it to form a complete solution.

Note: After seeing this tweet from Ron Oglesby, Is Antivirus Software a Waste of Money?, maybe this is a complete waste of time:-)

Mar
01

#VDI Tip 64: Follow the Network Checklist

Funny thing about Virtual Desktop Infrastructure, it usually relies heavily on the network. Most of my last two days has been spent troubling shooting dropped PCoIP packets, so I feel it’s timely to make sure you have your basis covered.

So here is the big tip of the day, Read and follow this check list – PCoIP Virtual Desktop Network Design Checklist

Networking isn’t my strongest skill but luckily I work with some really smart people. I think the biggest take away from the checklist is WRED.(Weighted Random Early Detection). It provides preferential traffic handling for packets with higher priority. It can selectively discard lower priority traffic when the interface begins to get congested. Try to get your PCoIP traffic prioritized just under VoIP traffic. The above document notes ” Do not configure WRED on the physical interface as it will override all other QoS policies”. Most traffic monitoring tools are not granularity enough to catch the spikes in traffic. In the land PCoIP, 1 minute intervals does not pass the test.

If you have access to your Cisco Router, you can check for drop packets by using the CEF (Cisco Express Forwarding) commands.
show cef drop
show ip cef switching statistics

You can also check for high CPU utilization. Sometimes high CPU utilization will cause buffering. Buffering = BAD

Run something different than Cisco? Please comment and leave commands for other vendors.