1 / 16

VMware at SWFWMD

VMware at SWFWMD. What is SWFWMD. One of five regional water management districts for the state of Florida Four broad areas of responsibility: Water supply Flood protection Water quality Natural systems management. Where we were. Where we where at the last User group meeting:

maia
Download Presentation

VMware at SWFWMD

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. VMware at SWFWMD

  2. What is SWFWMD • One of five regional water management districts for the state of Florida • Four broad areas of responsibility: • Water supply • Flood protection • Water quality • Natural systems management

  3. Where we were • Where we where at the last User group meeting: • 20 ESX servers in Brooksville • 4 ESX Servers in Tampa • 2 ESX Servers in Bartow • 2 ESX Servers in Sarasota • Updated to 3.5.0 Upgrade 4 • 30 750 gig luns presented from San to Brooksville, 5 to Bartow, 4 to Sarasota and 4 to Tampa. • Approximately 340 VM servers and about 120 VM workstations

  4. Where we are • Where we are: • 21 ESX servers in Brooksville • 11 ESX Servers in Tampa 6 for disaster recovery • 2 ESX Servers in Bartow • 2 ESX Servers in Sarasota • ESX 3.5 Upgrade 4 • 34 750 gig luns presented from San to Brooksville, 5 to Bartow, 4 to Sarasota and 5 to Tampa. • Approximately 364 VM servers and about 100 VM workstations • Have reconfigured our clusters and set them up for each environment: Prod, Dev and Acceptance together, Workstations, Test, and DMZ.

  5. How we got to Where we are. • How we got to where we are: • New projects requiring more servers, Production, Development and acceptance • New VM commissioning is now driven by a ticketing process to minimize Ad Hoc machine creation. • Data Domain was acquired to cut down on the amount of space and time needed to complete backups. As everything else grows, space requirements are now almost exceeding our Data Domain Storage

  6. Data Domain • Data Domain is: • Deduplication Storage for Disk Backup, Archiving and Disaster Recovery • Data Domain deduplication storage systems dramatically reduce the amount of disk storage needed to retain and protect enterprise data. By identifying redundant files and data as they are being stored, Data Domain systems provide a storage footprint that is 10x-30x smaller, on average, than the original data set. Backup data can then be efficiently replicated and retrieved over existing networks for streamlined recovery

  7. Data Domain Configuration • Using Data Domain: • We use Vranger from Vizioncore in conjunction with our Data Domain • Had to set up a VMkernel port on each ESX server to communicate with Vranger. Must be in same subnet as Data Domain and ESX servers. • Directory structure had to be setup on Data Domain. • In Virtual Console you added the Data Domain share as an NFS (Network File System) storage device. • CIFS (Common Internet File System) is used to be able to view the directory structure in windows. This is used for file level restores from Vranger. • File level restores are now a matter of a few minutes as opposed to 20 – 40 minutes before. • .

  8. Data Domain Configuration • Data Domain Data Flow Overview • In this configuration there is no need for a physical server for Vranger.

  9. Data Domain Compression Bkvdd01 Total files: 6,676; bytes/storage_used: 15.5 Original Bytes: 18,623,202,707,194<-- This Compresses down Globally Compressed: 1,748,071,488,718 Locally Compressed: 1,198,773,732,400<-- to this Meta-data: 5,830,931,376 Bkvdd02 Total files: 20,181; bytes/storage_used: 14.7 Original Bytes: 51,641,147,968,000<-- This Compresses down Globally Compressed: 5,226,118,718,227 Locally Compressed: 3,500,575,126,843 <-- to this. Meta-data: 17,534,075,468

  10. VM Vsphere 4 and VM View • We have implemented a Vsphere test environment and are putting Vsphere through the paces . • So far we have set up ESX servers from scratch and upgraded existing ESX servers, all with no problems. • Have also setup Vizioncores Vranger 4.5 and has been a very good experience so far. Very user friendly, many new features that have made it so much easier to configure backup jobs and restores. The one major issue we had is that instead of NFS shares it uses Cifs shares to the Data Domain. Instead of using the VMkernel it needs to have the service console added to the DataDomain configuration

  11. VM Vsphere 4 and VM View • We have also setup a pilot of Virtual desktops using Vmware view. So far setup has been pretty straight forward following VMware's documentation. • We are streaming desktops to PC’s and a Wyse terminal (P20) which is designed to do PCOIP. This gives us an instant connection to the streamed desktop. It also has Dual monitor capabilities which was a little bit of a challenge to get working. After reverting back to the old driver and tweaking the video settings we were able to get this functional. Across the wan we are using 128 meg video memory. Performance so far is excellent across the wan. No response delays and video is crisp and playback of videos through the Microsoft media player is excellent. • We have also setup a Thinapp server and are streaming office, adobe and Firefox all to the virtual desktop.

  12. VM Vsphere 4 and VM View Major Components of VDI (View): • VMware infrastructure already in place • View Server • Clean templates of OS’s • Storage • Thinapp server if pushing apps Things to consider: • Storage of user Data: Network share • Local data should not exist in the desktop Image, use of roaming profiles • Server utilization (How many Virtual machines per each Vsphere Host) • Heavy Network Traffic • Outside users coming in (Virtual Desktop at home)

  13. VM Vsphere 4 and VM View Things To Consider (cont.) Redirection of profile folders to network share: Key folders you can redirect to reduce profile size include: • Application Data • My Documents • My Pictures • My Music • Desktop • Favorites • Cookies • Templates A benefit of redirecting all data is that you then need to archive or back up only the user data and base template. You do not need to back up each individual user’s View desktop.

  14. Lessons Learned • Lessons Learned: • A re-install of ESX 3.5 was performed on an existing server without pulling the fiber or disabling the fiber ports. This resulted in overwriting a SAN LUN with the ESX Operating System. VMware support was contacted to assist with this issue. As per instruction from the VMware support Engineer, VMconverter was utilized and successfully migrated machines from the ESX-Host memory to a new LUN. After two machines migrated the connection to the ESX –Host dropped and all machines had to be restored from Vranger backups. • Vsphere 4 has a nice upgrade tool that lets you know if your server is compliant for the Vsphere 4 upgrade saving time during the upgrade process.

  15. Where we are going • Where we are going: • Virtualizing as many servers as possible. We have about 14 more physical servers we can virtualize. • Moving our whole infrastructure to Vsphere 4 as we are standardizing on Windows 7 as our desktop configuration which can not be run on ESX 3.X. • Evaluating View and Citrix as Virtual desktop solutions and choosing which one will be utilized. • Moving to Vranger4, as our standard backup product for Vmware.

  16. Questions and Comments • Questions and Comments:

More Related