Yes, the new formula is correct. And I did not expect to see this so soon. Microsoft has announced that you can run Exchange 2003/2007 in a Virtual Server 2005 R2/Hyper-V virtualized environment and get Microsoft Professional Support Services. Here is the official Microsoft release about this. http://technet.microsoft.com/en-us/library/cc794548.aspx There are a details for each configuration (e.g. all 2007 roles supported except Unified Messaging), but this is a step in the right direction.
Also, Windows ITPro's article on this mentions that Microsoft has created a Server Virtualization Validation Program (SVVP) and that VMware is in the process of attempting to achieve certification. This is not a show stopper in my eyes since VMware supports clients Windows & Exchange hosts currently.
-Ben
Thursday, August 28, 2008
Saturday, August 23, 2008
First Experiences with VMware 3i
Overall, I love it. I'm might start drinking the VMware 3i koolaid. And if you're familiar with VMware Server, this will be an easy transition. Or if you are new, you'll need to hover over icons until you remember what they are. This is pretty easy though. If you don't know, 3i is now free. 3i is a slimmed down version of 3.5 which cuts multiple host type features (e.g. VMotion, Update Manager, etc).
So, I finally had some time today, and after reading all the documentation that came with my new server (Dell PowerEdge 2900 III) and inspecting the inside & removing the USB flash drive (Kingston 1GB) I fired it up. And yes, I normally read all documentation before I start to use a product. And boy, do I like the purr of a dual quad core, six 15k hard drive, & dual power supply server. After about 30 minutes, I actually turned off the music since it was bothering me and listened to the humming of the server.
Some notes on the 3i setup on my Dell. I quickly ran through the BIOS configuration and realized even though I had (read: paid / I don't have enough time in my life with my new daughter) Dell to pre-load 3i on this server, they did not enable the internal USB port to allow VMware 3i booting and on the CPU instructions, VT was disabled. If you recall from my previous blog posting, Intel's VT or AMD-V is a requirement. Nice touch Dell. After that, I booted it up, and 3i just loaded. I changed the root password and set the DHCP IP to static and then used another PC's web browser to download the VMware Infrastructure Client (aka VI Client) which is used to manage your ESx host. The only aspect of 3i I had to configure was storage. So, I gave all 6 hard drives in a RAID 10 configuration to VMware (file system is called VMFS, and I set the block size to 1MB, since I don't expect to have a single file over 256GB) to 3i. So, it handled the formating and everything. So, I now had 836GB of space.
After that, my first OS to install on my new VMware server was Windows 2008 Standard 64 bit. You run through adding a new virtual machine, and I select a CPU, 1GB of ram, and 20GB of hard drive space and place the install CD on your local PC and then select "Connect DVD" and your local DVD/CD automatically appears on the "server vm". I was running this via a 10/100 network, and the install proceeded very quickly compared to Windows 2003. Keep in mind, I had never installed 2008 before. It went very smoothly the install. No issues on install or setup. But, little did I know, the new server OS takes over 10.5GB of space. Holy smokes. I guess I'll be re-installing Windows 2008 again. Oh well.
The management console shows quite a number of performance related statistics (e.g. overall memory usage, network, hard drive, etc) for all virtual machines. Like I initially said, anyone with any VMware Workstation/Server experience will feel right at home, otherwise it's still fairly easy to get around. I'll post again once I dig deeper in the product.
-Ben
P.S. Comments or feedback is always welcome.
So, I finally had some time today, and after reading all the documentation that came with my new server (Dell PowerEdge 2900 III) and inspecting the inside & removing the USB flash drive (Kingston 1GB) I fired it up. And yes, I normally read all documentation before I start to use a product. And boy, do I like the purr of a dual quad core, six 15k hard drive, & dual power supply server. After about 30 minutes, I actually turned off the music since it was bothering me and listened to the humming of the server.
Some notes on the 3i setup on my Dell. I quickly ran through the BIOS configuration and realized even though I had (read: paid / I don't have enough time in my life with my new daughter) Dell to pre-load 3i on this server, they did not enable the internal USB port to allow VMware 3i booting and on the CPU instructions, VT was disabled. If you recall from my previous blog posting, Intel's VT or AMD-V is a requirement. Nice touch Dell. After that, I booted it up, and 3i just loaded. I changed the root password and set the DHCP IP to static and then used another PC's web browser to download the VMware Infrastructure Client (aka VI Client) which is used to manage your ESx host. The only aspect of 3i I had to configure was storage. So, I gave all 6 hard drives in a RAID 10 configuration to VMware (file system is called VMFS, and I set the block size to 1MB, since I don't expect to have a single file over 256GB) to 3i. So, it handled the formating and everything. So, I now had 836GB of space.
After that, my first OS to install on my new VMware server was Windows 2008 Standard 64 bit. You run through adding a new virtual machine, and I select a CPU, 1GB of ram, and 20GB of hard drive space and place the install CD on your local PC and then select "Connect DVD" and your local DVD/CD automatically appears on the "server vm". I was running this via a 10/100 network, and the install proceeded very quickly compared to Windows 2003. Keep in mind, I had never installed 2008 before. It went very smoothly the install. No issues on install or setup. But, little did I know, the new server OS takes over 10.5GB of space. Holy smokes. I guess I'll be re-installing Windows 2008 again. Oh well.
The management console shows quite a number of performance related statistics (e.g. overall memory usage, network, hard drive, etc) for all virtual machines. Like I initially said, anyone with any VMware Workstation/Server experience will feel right at home, otherwise it's still fairly easy to get around. I'll post again once I dig deeper in the product.
-Ben
P.S. Comments or feedback is always welcome.
Labels:
3i,
first experiences,
VMware ESx,
Windows 2008
Monday, August 18, 2008
Virtualization Performance is better than you think for Exchange Server
Hello Everyone,
The common thought is Exchange Server does not get virtualized. But, I'll tell you what, Exchange should be virtualized. Applications that are mission critical should be protected using a number of backup, high availability, and fail-over type solutions. I consider virtualization a method of fail-over.
The biggest concern I frequently hear about Exchange is performance (after complexity - I would disagree on that one). Well, the performance difference between virtual and physical environments (at least VMware ESx, haven't seen performance benchmarks of Hyper-V) is a lot closer than one would expect when properly configured (I don't want to hear about the single SATA hard drive configuration you are running with 1GB of ram). I'll summarize the technical details of a performance test of Exchange 2003, VMware ESx 3.0 on fibre channel on Dell/EMC hardware (all 32 bit, 2GB of memory only). URL for the report is here in PDF.
Close Ball-Game
1) a single virtual CPU could obtain 76% performance of a physical CPU (clocked at 1300 heavy user profiles with acceptable performance using LoadSim, Microsoft's Outlook/Exchange testing tool)
2) 2 virtual CPUs could obtain 71% performance of a 2 physical CPU solution (support for up to 2200 heavy user profiles)
3) CPU Utilization - 30% difference in utilization, but not an issue. Exchange is not a heavy CPU user. More important to focus on I/O and memory.
4) VMware's memory sharing technology did not show any performance degradation.
One of the biggest surprises for me was the VMware memory sharing technology had no effect. I'll be taking a closer look at this in other benchmarks and personal testing since it's hard to believe that there was no difference. Just to re-cap the memory sharing technology, if you run 4 virtual machines (aka vm) with Windows 2003 Server, you're running many of the same services (e.g. netlogon.exe, explorer.exe, etc) which consume the same memory, so VMware does a "single instance" type memory sharing between all 4 vm's.
To summarize, if you have the I/O capabilities and want to improve your business continuity solutions, I would consider looking into this further. I wouldn't just count this out. And I plan to run my Exchange Server in ESx very soon. Hope to see you there...
-Ben
The common thought is Exchange Server does not get virtualized. But, I'll tell you what, Exchange should be virtualized. Applications that are mission critical should be protected using a number of backup, high availability, and fail-over type solutions. I consider virtualization a method of fail-over.
The biggest concern I frequently hear about Exchange is performance (after complexity - I would disagree on that one). Well, the performance difference between virtual and physical environments (at least VMware ESx, haven't seen performance benchmarks of Hyper-V) is a lot closer than one would expect when properly configured (I don't want to hear about the single SATA hard drive configuration you are running with 1GB of ram). I'll summarize the technical details of a performance test of Exchange 2003, VMware ESx 3.0 on fibre channel on Dell/EMC hardware (all 32 bit, 2GB of memory only). URL for the report is here in PDF.
Close Ball-Game
1) a single virtual CPU could obtain 76% performance of a physical CPU (clocked at 1300 heavy user profiles with acceptable performance using LoadSim, Microsoft's Outlook/Exchange testing tool)
2) 2 virtual CPUs could obtain 71% performance of a 2 physical CPU solution (support for up to 2200 heavy user profiles)
3) CPU Utilization - 30% difference in utilization, but not an issue. Exchange is not a heavy CPU user. More important to focus on I/O and memory.
4) VMware's memory sharing technology did not show any performance degradation.
One of the biggest surprises for me was the VMware memory sharing technology had no effect. I'll be taking a closer look at this in other benchmarks and personal testing since it's hard to believe that there was no difference. Just to re-cap the memory sharing technology, if you run 4 virtual machines (aka vm) with Windows 2003 Server, you're running many of the same services (e.g. netlogon.exe, explorer.exe, etc) which consume the same memory, so VMware does a "single instance" type memory sharing between all 4 vm's.
To summarize, if you have the I/O capabilities and want to improve your business continuity solutions, I would consider looking into this further. I wouldn't just count this out. And I plan to run my Exchange Server in ESx very soon. Hope to see you there...
-Ben
Monday, August 11, 2008
Serious DNS Vulnerability (Kaminsky) Can Affect Email Services
Hello All,
This is the beginning of shorter posts, but more often.
This recently released serious DNS vulnerability (found by Kaminsky) can affect email services, so while hackers are spoofing DNS for web site attacks, the same could be done for email attacks. See the US-Cert for an overview of the issue. This effects dozens of DNS implementations including Windows DNS.
Official US-Cert Posting on the DNS Vulnerability
http://www.kb.cert.org/vuls/id/800113
An Illustrated Guide to the Problem
http://www.unixwiz.net/techtips/iguide-kaminsky-dns-vuln.html
There is some discussions about what the best approach is to fix it (e.g. DNSSEC, increase Query ID, randomize the source port, IPv6, SSL, etc). So, it at the moment, the easiest fix is increase the query ID and randomize the source port. For your servers, use (at least for Windows Server DNS), the root based hints included in the operating system. "Man in the middle" attacks are a lot more common and dangerous than people realize, hence why I prefer using my EVDO card than some random WiFi hotspot. Stay safe.
-Ben
This is the beginning of shorter posts, but more often.
This recently released serious DNS vulnerability (found by Kaminsky) can affect email services, so while hackers are spoofing DNS for web site attacks, the same could be done for email attacks. See the US-Cert for an overview of the issue. This effects dozens of DNS implementations including Windows DNS.
Official US-Cert Posting on the DNS Vulnerability
http://www.kb.cert.org/vuls/id/800113
An Illustrated Guide to the Problem
http://www.unixwiz.net/techtips/iguide-kaminsky-dns-vuln.html
There is some discussions about what the best approach is to fix it (e.g. DNSSEC, increase Query ID, randomize the source port, IPv6, SSL, etc). So, it at the moment, the easiest fix is increase the query ID and randomize the source port. For your servers, use (at least for Windows Server DNS), the root based hints included in the operating system. "Man in the middle" attacks are a lot more common and dangerous than people realize, hence why I prefer using my EVDO card than some random WiFi hotspot. Stay safe.
-Ben
Tuesday, July 22, 2008
When is 64 bit not really 64 bit?
Hello Everyone,
My journey, and I can call it that, for deploying a test environment (running multiple OSes, 32 & 64 bit OSes) based on VMware ESx 3.5 has taken a LOT longer than I expected and has taught me a thing or two about 64 bit. This also explains the bigger problem affecting the uptake of "64 bit" products and how with an idea if adopted can hopefully help dramatically increase admins buying into "64 bit".
There is a lot of talk about 64 bit applications, 64 bit operating systems, 64 bit hardware and all the wonderful things it brings. Well, that might be true, but the current software & hardware state of affairs is that 64 bit is not really 64 bit and can cause a lot of headaches, delays, and stress. Most vendors do not seem to be ready for it. Many "64 bit" applications are coded to run using an emulator (WoW64) for insuring "64 bit" compatibility, a software package might have some 64 bit apps but not all, lack of what level of 64 bit hardware is required, and others. Why? My guess is lack of clear standards and documentation. There is an answer though! 64 bit needs an easy to understand marketing association that can help insure end users that when something says 64 bit, it really is. Something similar to the hugely success compatibility standard called Wi-Fi (aka 802.11b). When someone bought a Wi-Fi card by one manufacturer and an access point by another, there was no doubt it would work. Why? The Wi-FI Alliance tested for compatibility and worked with vendors to insure everything "just worked". This is what we need for "64 bit" if we think it's going to take off. Otherwise, everyone will stick with "32 bit" until it simply does not exist anymore and based on that, that will be a long time. So, Microsoft, Intel, AMD, IBM, etc need to create a 64-bit alliance or call the Wi-Fi Alliance for some marketing assistance. Let's call it "64 bit-Tested for Performance" and a check-mark. Plaster that logo on everything that is fully 64 bit developed & supports Intel's VT or AMD-V.
Now, back to my story about my journey of ESx starting around January 2008 with no end in sight yet. The first step for VMware ESx 3.5 or Hyper-V 1.0 is a foundation based on a quality server. I considered a generic box, but realized, that ESx has a compatibility list (aka Systems Guide http://www.vmware.com/pdf/vi35_systems_guide.pdf) for servers due to the drivers since it installs on bare metal (no Windows here folks). So I strongly strongly recommend you read that to insure the server, cpu, and RAID card are all compatible. Hyper-V's requirements are a lot easier since if Windows 2008 installs and it support Intel VT or AMD-V, you *should* be good to go. I've included below all the CPUs that support virtualization.
On to my VMware sage. The first server hardware I attempted to use was an IBM x346. I purchased all the components (e.g. dual core CPUs, 16GB of ram, 6 x Fijitsu U320 300GB 10k HDs) and was ready to start the process. To make a long story short and summarize, the IBM server I was using does not like end users using non-IBM hard drives and a serious bug causing HDs to go offline which affected an entire line of RAID controllers card which prevented the use of the server. I did quite a bit of research and in the end the only answer I found was to replace the HDs with same Fujitsu model # HDs but IBM branded for $1300/each (about $1k more than I paid per drive) or use other IBM branded HDs. Another major flaw in the design of the IBM branded RAID card 7k is the need to boot an IBM RAID CD to gain access to almost any functionality (put a HD back online, replace it, config change, etc). This is horrible and slow process compared to Adaptec, Dell, or HP cards where you simply enter into the card BIOS by pushing a key combination and you make all your changes there. I was not impressed with my first foray with an IBM server. So, I will not be upset if it's my last. Goodbye IBM Servers.
Further reading on my battle with the IBM x346 Server.
To read the issue in more detail, check this out. I'm Benx346 if you're in doubt.
http://www.ibm.com/developerworks/forums/thread.jspa?threadID=207574&tstart=0
A "friend" suggested that I try and replace the IBM RAID card with an Adaptec (on VMware compatibilty list) and then connect the new RAID card to the backplane connector with my replacement SCSI cable. Well, a month or so later and trying to get SCSI cabling companies to custom manufacturer a SCSI cable simply isn't possible unless I plan to buy 1000 units. Feel free to look at the rare SCSI connector (micro centronics 80 female SCA) I was dealing with.
http://photos.serebin.com/gallery2/v/ben/temp/ibmx346-cable
Content Alert: anyone who can find me an 18" micro centronics 80 female SCA to LVD high density 68 pin male with ultra 320 data speeds will get a $100 reward.
The 2nd server was a Dell PowerEdge 2850 which supports 2 x dual core 64 bit 2.8GHz CPUs, 6 x UltraSCSI 320 HDs, and 16GB of ram. The unit arrived dead on arrival. So, the vendor only had one unit since it was off lease and ended up credit-ing me back for it. Still no server after 6 months. One of the major downsides of eBay. Things frequently take longer.
3rd Server was a Dell PowerEdge 2850 from another vendor I found via eBay which arrived operational (there are many companies that work with companies giving up servers on leases). I took the 6 HDs from the IBM x346 and installed them and configured them for RAID 10. Moved over 12GB of the memory (only 6 slots versus the 8 on the IBM) and powered it up. Still good and very fast. So, I installed Windows 2003 32 bit, and it went smoothly. I then reinstalled with Windows 2003 R2 64 bit and started my 48 hour burn-in. This burn-in stresses the hard drives, CPU, & ram. The application I use is PassMark's BurnInTest (http://www.passmark.com/products/bit.htm). Make sure you buy the "Pro" version for 64 bit support. Then I started looking at upgrading the ram to 4GB chips to hit the magic 16GB of ram of which I had calculated to need. I'm not sure what caused me to look at this, but something caught my eye. It turns out ESx 3.0 & 3.5 does not support 64 bit OSes without hardware assisted virtualization (e.g. Intel's VT or AMD-V). I was shocked. I wondered why does VMware Workstation, VMware Server, Microsoft Virtual Server support 64 bit OSes without hardware assistance? The reason was performance. VMware felt performance was too big of an issue, so it was removed. But at least 64 bit was an option under those applications. To be honest, CPU performance is rarely the bottleneck for VMware Workstation/Server or Microsoft Virtual Server, it's I/O which is all hard drive based bottlenecks. So, now I'm back in search of another server. I'll probably bite the bullet and purchase a new Dell Server 2950 Series III or 2970 since I'm familiar with them. Once I start my environment, I'll definitely share it with the blog.
As per the lesson, make sure you know what is required for "64 bit" support. Is this a full 64 bit application (as opposed to a 64 bit application with 32 bit components), 64 bit operating system without 32 bit legacy support, or need for what I refer to as v2 of 64 bit CPU which is the CPU virtualization feature called Intel's VT or AMD-V. Or check and make sure it contains the logo of "64 bit-Tested for Performance" or I can only hope for that.
Best of luck with your "64 bit" projects,
-Ben
CPUs Support Virtualization with the Intel VT or AMD-V Feature.
Intel's Website for it as well
http://compare.intel.com/PCC/default.aspx?familyid=5&culture=en-US
Intel Quad-Core CPUs Series supporting VT
- Xeon 7300, 5400, 5300, 3000, X3200, LV
Intel Dual-Core CPUs Series supporting VT
- Xeon 7000, 5200, 3070, 3065, 3060, 3050, 3040, E3100 (fyi: not all 3000 series are supported)
AMD CPUs Series Supporting AMD-V (Virtualization)
- Opteron 1000, 2000, 8000
AMD does not have a website that I've found as easy to use.
------------------------------------------
My journey, and I can call it that, for deploying a test environment (running multiple OSes, 32 & 64 bit OSes) based on VMware ESx 3.5 has taken a LOT longer than I expected and has taught me a thing or two about 64 bit. This also explains the bigger problem affecting the uptake of "64 bit" products and how with an idea if adopted can hopefully help dramatically increase admins buying into "64 bit".
There is a lot of talk about 64 bit applications, 64 bit operating systems, 64 bit hardware and all the wonderful things it brings. Well, that might be true, but the current software & hardware state of affairs is that 64 bit is not really 64 bit and can cause a lot of headaches, delays, and stress. Most vendors do not seem to be ready for it. Many "64 bit" applications are coded to run using an emulator (WoW64) for insuring "64 bit" compatibility, a software package might have some 64 bit apps but not all, lack of what level of 64 bit hardware is required, and others. Why? My guess is lack of clear standards and documentation. There is an answer though! 64 bit needs an easy to understand marketing association that can help insure end users that when something says 64 bit, it really is. Something similar to the hugely success compatibility standard called Wi-Fi (aka 802.11b). When someone bought a Wi-Fi card by one manufacturer and an access point by another, there was no doubt it would work. Why? The Wi-FI Alliance tested for compatibility and worked with vendors to insure everything "just worked". This is what we need for "64 bit" if we think it's going to take off. Otherwise, everyone will stick with "32 bit" until it simply does not exist anymore and based on that, that will be a long time. So, Microsoft, Intel, AMD, IBM, etc need to create a 64-bit alliance or call the Wi-Fi Alliance for some marketing assistance. Let's call it "64 bit-Tested for Performance" and a check-mark. Plaster that logo on everything that is fully 64 bit developed & supports Intel's VT or AMD-V.
Now, back to my story about my journey of ESx starting around January 2008 with no end in sight yet. The first step for VMware ESx 3.5 or Hyper-V 1.0 is a foundation based on a quality server. I considered a generic box, but realized, that ESx has a compatibility list (aka Systems Guide http://www.vmware.com/pdf/vi35_systems_guide.pdf) for servers due to the drivers since it installs on bare metal (no Windows here folks). So I strongly strongly recommend you read that to insure the server, cpu, and RAID card are all compatible. Hyper-V's requirements are a lot easier since if Windows 2008 installs and it support Intel VT or AMD-V, you *should* be good to go. I've included below all the CPUs that support virtualization.
On to my VMware sage. The first server hardware I attempted to use was an IBM x346. I purchased all the components (e.g. dual core CPUs, 16GB of ram, 6 x Fijitsu U320 300GB 10k HDs) and was ready to start the process. To make a long story short and summarize, the IBM server I was using does not like end users using non-IBM hard drives and a serious bug causing HDs to go offline which affected an entire line of RAID controllers card which prevented the use of the server. I did quite a bit of research and in the end the only answer I found was to replace the HDs with same Fujitsu model # HDs but IBM branded for $1300/each (about $1k more than I paid per drive) or use other IBM branded HDs. Another major flaw in the design of the IBM branded RAID card 7k is the need to boot an IBM RAID CD to gain access to almost any functionality (put a HD back online, replace it, config change, etc). This is horrible and slow process compared to Adaptec, Dell, or HP cards where you simply enter into the card BIOS by pushing a key combination and you make all your changes there. I was not impressed with my first foray with an IBM server. So, I will not be upset if it's my last. Goodbye IBM Servers.
Further reading on my battle with the IBM x346 Server.
To read the issue in more detail, check this out. I'm Benx346 if you're in doubt.
http://www.ibm.com/developerworks/forums/thread.jspa?threadID=207574&tstart=0
A "friend" suggested that I try and replace the IBM RAID card with an Adaptec (on VMware compatibilty list) and then connect the new RAID card to the backplane connector with my replacement SCSI cable. Well, a month or so later and trying to get SCSI cabling companies to custom manufacturer a SCSI cable simply isn't possible unless I plan to buy 1000 units. Feel free to look at the rare SCSI connector (micro centronics 80 female SCA) I was dealing with.
http://photos.serebin.com/gallery2/v/ben/temp/ibmx346-cable
Content Alert: anyone who can find me an 18" micro centronics 80 female SCA to LVD high density 68 pin male with ultra 320 data speeds will get a $100 reward.
The 2nd server was a Dell PowerEdge 2850 which supports 2 x dual core 64 bit 2.8GHz CPUs, 6 x UltraSCSI 320 HDs, and 16GB of ram. The unit arrived dead on arrival. So, the vendor only had one unit since it was off lease and ended up credit-ing me back for it. Still no server after 6 months. One of the major downsides of eBay. Things frequently take longer.
3rd Server was a Dell PowerEdge 2850 from another vendor I found via eBay which arrived operational (there are many companies that work with companies giving up servers on leases). I took the 6 HDs from the IBM x346 and installed them and configured them for RAID 10. Moved over 12GB of the memory (only 6 slots versus the 8 on the IBM) and powered it up. Still good and very fast. So, I installed Windows 2003 32 bit, and it went smoothly. I then reinstalled with Windows 2003 R2 64 bit and started my 48 hour burn-in. This burn-in stresses the hard drives, CPU, & ram. The application I use is PassMark's BurnInTest (http://www.passmark.com/products/bit.htm). Make sure you buy the "Pro" version for 64 bit support. Then I started looking at upgrading the ram to 4GB chips to hit the magic 16GB of ram of which I had calculated to need. I'm not sure what caused me to look at this, but something caught my eye. It turns out ESx 3.0 & 3.5 does not support 64 bit OSes without hardware assisted virtualization (e.g. Intel's VT or AMD-V). I was shocked. I wondered why does VMware Workstation, VMware Server, Microsoft Virtual Server support 64 bit OSes without hardware assistance? The reason was performance. VMware felt performance was too big of an issue, so it was removed. But at least 64 bit was an option under those applications. To be honest, CPU performance is rarely the bottleneck for VMware Workstation/Server or Microsoft Virtual Server, it's I/O which is all hard drive based bottlenecks. So, now I'm back in search of another server. I'll probably bite the bullet and purchase a new Dell Server 2950 Series III or 2970 since I'm familiar with them. Once I start my environment, I'll definitely share it with the blog.
As per the lesson, make sure you know what is required for "64 bit" support. Is this a full 64 bit application (as opposed to a 64 bit application with 32 bit components), 64 bit operating system without 32 bit legacy support, or need for what I refer to as v2 of 64 bit CPU which is the CPU virtualization feature called Intel's VT or AMD-V. Or check and make sure it contains the logo of "64 bit-Tested for Performance" or I can only hope for that.
Best of luck with your "64 bit" projects,
-Ben
CPUs Support Virtualization with the Intel VT or AMD-V Feature.
Intel's Website for it as well
http://compare.intel.com/PCC/default.aspx?familyid=5&culture=en-US
Intel Quad-Core CPUs Series supporting VT
- Xeon 7300, 5400, 5300, 3000, X3200, LV
Intel Dual-Core CPUs Series supporting VT
- Xeon 7000, 5200, 3070, 3065, 3060, 3050, 3040, E3100 (fyi: not all 3000 series are supported)
AMD CPUs Series Supporting AMD-V (Virtualization)
- Opteron 1000, 2000, 8000
AMD does not have a website that I've found as easy to use.
------------------------------------------
Labels:
32 bit,
64 bit,
AMD-V,
Hyper V,
IBM ServeRAID 7k,
Intel VT,
VMware ESx
Friday, July 4, 2008
A Solid Lie on Solid State (Hard) Drives
Hello Everyone,
Happy July 4th. Quick multiple question test. A Solid State Drive includes which features?
A) Flash-based storage
B) Rugged and reliable
C) Low power consumption
D) High performance
E) Silent operation
F) Lightweight
G) All of the Above
If you answered "G", you're wrong! It turns out that low power consumption is not correct (only mistake above). SSDs actually use MORE power and so they reduce battery life on laptops compared to traditional hard drives. Many of the SSD vendors claim battery life is improved, but this is not the case. Crucial as of 7/4/08 listed the above features as benefits of SSDs. Sadly marketing cannot be trusted without independent tests. The folks at Tom's Hardware uncovered this little "lie" in an article called "The SSD Power Consumption Hoax: Flash SSDs Don't Improve Your Notebook Battery Runtime - they Reduce It". That title alone illuminates the issue, but dig into the article and testing and you see performance gains of about 10% for SSDs but battery life differences of an hour (15-20% difference)! How can that be possible? Turns out SSDs don't have an idle power mode like traditional hard drives do. So, they you're traditional hard drive is not working, it's using very little power, but not SSDs. They are always on. Whoops.
Also, the tests would have been a lot worse for SSDs if Tom's hardware had picked a 4200 or 5400 rpm drive. They used a power hungry 7200 rpm drive, and the difference was still as clear as night and day. Don't select SSDs for power savings, but for durability and speed. I was considering a Mtron SSD back in Feb 08 for performance and power reasons on my ultra-portable semi-rugged Panasonic Toughbook W5, luckily I decided against it since I wanted a 64GB SSD, and they were still too costly. Mtron does make excellent SSDs, so I would recommend folks look into them if battery life isn't an issue.
Summary of SSDs
- overall, for improved laptop performance and keeping battery life acceptable, I would stick with 7200 rpm HDs (10% performance difference)
- battery is a serious issue for SSDs (15-20% loss), right now. I suspect due to the Tom's Hardware article, this will draw attention to the issue and the next versions (6-12 months) will improve dramatically
- be aware there are 2 types of SSDs, SLC and MLC. SLC is faster and more durable. So, stick with SLC for the moment if you want to consider SSDs.
Comments and feedback is welcome...
-Ben
Happy July 4th. Quick multiple question test. A Solid State Drive includes which features?
A) Flash-based storage
B) Rugged and reliable
C) Low power consumption
D) High performance
E) Silent operation
F) Lightweight
G) All of the Above
If you answered "G", you're wrong! It turns out that low power consumption is not correct (only mistake above). SSDs actually use MORE power and so they reduce battery life on laptops compared to traditional hard drives. Many of the SSD vendors claim battery life is improved, but this is not the case. Crucial as of 7/4/08 listed the above features as benefits of SSDs. Sadly marketing cannot be trusted without independent tests. The folks at Tom's Hardware uncovered this little "lie" in an article called "The SSD Power Consumption Hoax: Flash SSDs Don't Improve Your Notebook Battery Runtime - they Reduce It". That title alone illuminates the issue, but dig into the article and testing and you see performance gains of about 10% for SSDs but battery life differences of an hour (15-20% difference)! How can that be possible? Turns out SSDs don't have an idle power mode like traditional hard drives do. So, they you're traditional hard drive is not working, it's using very little power, but not SSDs. They are always on. Whoops.
Also, the tests would have been a lot worse for SSDs if Tom's hardware had picked a 4200 or 5400 rpm drive. They used a power hungry 7200 rpm drive, and the difference was still as clear as night and day. Don't select SSDs for power savings, but for durability and speed. I was considering a Mtron SSD back in Feb 08 for performance and power reasons on my ultra-portable semi-rugged Panasonic Toughbook W5, luckily I decided against it since I wanted a 64GB SSD, and they were still too costly. Mtron does make excellent SSDs, so I would recommend folks look into them if battery life isn't an issue.
Summary of SSDs
- overall, for improved laptop performance and keeping battery life acceptable, I would stick with 7200 rpm HDs (10% performance difference)
- battery is a serious issue for SSDs (15-20% loss), right now. I suspect due to the Tom's Hardware article, this will draw attention to the issue and the next versions (6-12 months) will improve dramatically
- be aware there are 2 types of SSDs, SLC and MLC. SLC is faster and more durable. So, stick with SLC for the moment if you want to consider SSDs.
Comments and feedback is welcome...
-Ben
Monday, June 30, 2008
"Cheating" on an Exchange 2003 Hardware Upgrade
Hello Everyone,
I "cheated" on an Exchange 2003 hardware upgrade I did 2 weekends ago (Fri-Sat), or that's at least how I feel since this was hands down the fastest and easiest upgrade I've ever done (and it was about 80GB of db's on an older server with direct attached storage). At the end of the weekend, I started to think maybe I should carry around one of these "things" for my clients for upgrades. I'll share what this "thing" was later in the posting. I don't want folks to think I'm pushing products. My role in the project was to insure the replacement of the Exchange Server hardware went smoothly. The client was in production 24/7 and literally the office was staffed 6 days a week. So, I was concerned originally how to insure minimal downtime.
Background on existing hardware & performance
We were upgrading from an Exchange 2003 Server that was installed with 3 hard drives in a RAID 5 hard drive configuration (direct attached storage) for the OS, transaction logs, and Exchange databases. Company had about 60 users and 30 BlackBerrys or so. 1 BES user adds a load similar to 2 Outlook users. So, total company usage was about 120 users. Performance was an issue, so some users were configured for cached mode to "improve" performance. Cached mode should not be required for LANs, unless Outlook end users are receiving "retrieving data from server". Always a bad sign to see unless you have poor network connection. Recommended another DAS server that used RAID 1 for the OS, RAID 1 for transaction logs, and RAID 10 for the Exchange databases.
The Migration for a hardware refresh
So, I checked the OS install (another admin handled that), Exchange install (using the /disasterrecovery switch for setup and service pack 2), Exchange config, and insuring the email & public folder migration completed successful. Only catch was during this server replacement, there was to be no downtime and no use of Exchange clustered services. Hmmm, that's a challenge. Or so one would think.
The Cheat
The client I was working for happened to have a 3rd party product (keeping read to find out) for Exchange that in essence allowed the "cheating". And I mean this in a very good way. It saved us a LOT of time. Meaning, we told the 3rd party product to take over all the existing Exchange services (MAPI, SMTP, OWA, IMAP, etc) and all data for the Outlook, OWA, ActiveSync, & BlackBerry was available to all users. This took a few minutes (3 or 4 minutes) on the switch-over. Meaning the appliance takes some time to take control. Once that was done, everyone was operating off the appliance and end users didn't know this besides restarting Outlook and re-authenticating to OWA (ActiveSync & BES users had a slight delay. BES users could be out of service for up to 15 minutes, but that's a limitation of BES). Once the appliance took over, we copied over the Exchange databases (.edb/.stm's) using robocopy to the new Exchange 2003 Server. We considered upgrading to 2007, but the appliance and all the associated Exchange applications would have had to been upgraded, and it wasn't cost effective (TCO reminder). So, after we started robocopy-ing, we went home.
Day 2 of the Migration & Failback
I'm not going to go into the details, but migrating took a few hours including getting the SSL certs for OWA and handling all that. Once the new hardware was setup with Exchange, it was time to bring back all the new email. As I previously said, the reason to copy over the databases to the new server, was the appliance then doesn't need to copy over all data, and just new email/data. So, this is a huge time saver. Once we copied over the databases and transaction logs, we were able to get the Exchange Server fully operational and enable the failback from the appliance. We then failed back from the appliance to the new Exchange Server. This took a lot longer to check that all data was copied from the appliance to the new Exchange Server. This took 10 hours or so and then everyone had to relaunch Outlook and re-authenticate against the new server.
Appliance Details
The "cheat" was an Exchange high availability appliance from Teneros. Even though this appliance runs 2 operating systems, Linux and Windows, the entire configuration is on 2 web pages. Meaning, the Teneros support team is really what runs this product, not the Exchange admin. As per the web interface, to say the amount of information and configuration is sparse, is putting it lightly. Overall the product worked well and we ran into 2 glitches due to permissions and resetting process of the AD name due to poor documentation. And the migration process took longer than expected since the status of synchronization is not very accurate. Not a big deal, since end users are working during the failover and failback. Overall solution is very impressive, but I have some doubts since I'm not a big fan of trusting secret functionality of a black box type solution. I like to know how applications work and I do have concerns over Exchange updates or patches breaking the Teneros functionality. If you are curious, pricing is around $10k, give or take a few thousands. If you wanted to see the demo, Teneros did present at the NY Exchange User Group meeting back in November of December of 2007 or check out their website.
There are many other software solutions on the market that do this, and so I'll blog about when I work with them. My user group has had demo's and presentation on a # of them, but this was the first real world usage of one.
Let me know your thoughts on this.
-Ben
I "cheated" on an Exchange 2003 hardware upgrade I did 2 weekends ago (Fri-Sat), or that's at least how I feel since this was hands down the fastest and easiest upgrade I've ever done (and it was about 80GB of db's on an older server with direct attached storage). At the end of the weekend, I started to think maybe I should carry around one of these "things" for my clients for upgrades. I'll share what this "thing" was later in the posting. I don't want folks to think I'm pushing products. My role in the project was to insure the replacement of the Exchange Server hardware went smoothly. The client was in production 24/7 and literally the office was staffed 6 days a week. So, I was concerned originally how to insure minimal downtime.
Background on existing hardware & performance
We were upgrading from an Exchange 2003 Server that was installed with 3 hard drives in a RAID 5 hard drive configuration (direct attached storage) for the OS, transaction logs, and Exchange databases. Company had about 60 users and 30 BlackBerrys or so. 1 BES user adds a load similar to 2 Outlook users. So, total company usage was about 120 users. Performance was an issue, so some users were configured for cached mode to "improve" performance. Cached mode should not be required for LANs, unless Outlook end users are receiving "retrieving data from server". Always a bad sign to see unless you have poor network connection. Recommended another DAS server that used RAID 1 for the OS, RAID 1 for transaction logs, and RAID 10 for the Exchange databases.
The Migration for a hardware refresh
So, I checked the OS install (another admin handled that), Exchange install (using the /disasterrecovery switch for setup and service pack 2), Exchange config, and insuring the email & public folder migration completed successful. Only catch was during this server replacement, there was to be no downtime and no use of Exchange clustered services. Hmmm, that's a challenge. Or so one would think.
The Cheat
The client I was working for happened to have a 3rd party product (keeping read to find out) for Exchange that in essence allowed the "cheating". And I mean this in a very good way. It saved us a LOT of time. Meaning, we told the 3rd party product to take over all the existing Exchange services (MAPI, SMTP, OWA, IMAP, etc) and all data for the Outlook, OWA, ActiveSync, & BlackBerry was available to all users. This took a few minutes (3 or 4 minutes) on the switch-over. Meaning the appliance takes some time to take control. Once that was done, everyone was operating off the appliance and end users didn't know this besides restarting Outlook and re-authenticating to OWA (ActiveSync & BES users had a slight delay. BES users could be out of service for up to 15 minutes, but that's a limitation of BES). Once the appliance took over, we copied over the Exchange databases (.edb/.stm's) using robocopy to the new Exchange 2003 Server. We considered upgrading to 2007, but the appliance and all the associated Exchange applications would have had to been upgraded, and it wasn't cost effective (TCO reminder). So, after we started robocopy-ing, we went home.
Day 2 of the Migration & Failback
I'm not going to go into the details, but migrating took a few hours including getting the SSL certs for OWA and handling all that. Once the new hardware was setup with Exchange, it was time to bring back all the new email. As I previously said, the reason to copy over the databases to the new server, was the appliance then doesn't need to copy over all data, and just new email/data. So, this is a huge time saver. Once we copied over the databases and transaction logs, we were able to get the Exchange Server fully operational and enable the failback from the appliance. We then failed back from the appliance to the new Exchange Server. This took a lot longer to check that all data was copied from the appliance to the new Exchange Server. This took 10 hours or so and then everyone had to relaunch Outlook and re-authenticate against the new server.
Appliance Details
The "cheat" was an Exchange high availability appliance from Teneros. Even though this appliance runs 2 operating systems, Linux and Windows, the entire configuration is on 2 web pages. Meaning, the Teneros support team is really what runs this product, not the Exchange admin. As per the web interface, to say the amount of information and configuration is sparse, is putting it lightly. Overall the product worked well and we ran into 2 glitches due to permissions and resetting process of the AD name due to poor documentation. And the migration process took longer than expected since the status of synchronization is not very accurate. Not a big deal, since end users are working during the failover and failback. Overall solution is very impressive, but I have some doubts since I'm not a big fan of trusting secret functionality of a black box type solution. I like to know how applications work and I do have concerns over Exchange updates or patches breaking the Teneros functionality. If you are curious, pricing is around $10k, give or take a few thousands. If you wanted to see the demo, Teneros did present at the NY Exchange User Group meeting back in November of December of 2007 or check out their website.
There are many other software solutions on the market that do this, and so I'll blog about when I work with them. My user group has had demo's and presentation on a # of them, but this was the first real world usage of one.
Let me know your thoughts on this.
-Ben
Labels:
Exchange Server 2003,
migration,
robocopy,
Teneros
Subscribe to:
Posts (Atom)