Friday, December 30, 2011

Virtualizing Microsoft SQL Server

The SQL performance team has published a document related to the use of SQL 2008 in a Hyper-V environment. A few of the key items are listed in this section, but it is strongly suggested that you download and review this document in its entirety prior to implementing SQL in a Hyper-V environment. To download this SQL team’s document, go to http://download.microsoft.com/download/d/9/4/d948f981-926e-40fa-a026-5bfcf076d9b9/SQL2008inHyperV2008.docx.

Use a synthetic network adapter provided by the Hyper-V Integration tools instead of a legacy network adapter when configuring networking for the virtual machine.

Avoid emulated devices for SQL Server deployments when possible. These devices can result in significantly more CPU overhead when compared to synthetic devices. SQL Server is I/O intensive, so it is recommended that you use the pass-through disk option as opposed to the fixed-size Virtual Hard Disks (VHDs). Dynamic VHDs are not recommended for performance reasons.

In the SQL Team’s document, they used locally attached storage on the Hyper-V server. Many virtual hosts are connected to shared storage using Fiber Channel, iSCSI, or NFS. Selecting the proper storage connection will greatly impact the I/O performance of the virtual SQL Server.

Source of Information : Elsevier-Microsoft Virtualization Master Microsoft Server Desktop Application and Presentation

Tuesday, December 27, 2011

Virtualizing Microsoft exchange server

Virtualizing Exchange has been a topic of great controversy ever since virtualization first came on the scene. In the early years of virtualization, it was recommended NOT to run Exchange in a virtual environment because of the limitations of the infant technology. Since then, virtualization has matured in a way that has removed many, if not all, of those limitations. Unfortunately, the recommendations of the past have remained as a worry in today’s discussions surrounding the partnership of virtualization and Exchange. The truth is Microsoft fully supports the virtualization of Microsoft Exchange today. As with any other environment, you must be sure that you configure your virtual platform to properly support Exchange, but there are no limitations within Microsoft’s Hyper-V technology that should cause any concern in your discussions to virtualize Exchange. There are some key items that Microsoft has called out that IS professionals should be aware of when designing their virtual Exchange environments.

- The software platform should be Windows Server 2008, or any thirdparty vendor virtualization platform that has been validated by Microsoft’s Windows Server Virtualization Validation Program. Located here: www.windowsservercatalog.com/svvp.aspx?svvppage¼svvp.htm, the Validation Program includes some of the most well-known vendors of both hardware and software. The site will help you to identify those who have been validated by Microsoft to provide platforms capable of running all flavors of the Microsoft Servers.

- If you are planning to virtualize your Exchange environment, you must use Exchange Server 2007 with Service Pack 1 or later. Earlier, Exchange versions are not fully supported on a virtual platform. The use of the Unified Messaging role is not supported if your Exchange server is running within a virtual platform. It is important to note that the base Exchange 2007 system requirements WITHOUT the use of virtualization is Windows 2003, but the use of this operating system as a host for Exchange 2007 is not supported in the virtualization world. We mention this because some may consider building Exchange 2007 in a nonvirtual environment with the plan to migrate the complete operating system into Hyper-V at a later date. If you plan to do this, you must build your environment using Windows 2008 or later.

- Exchange 2007 on a virtual platform supports all of the most common forms of storage. These include virtual hard drives (VHD), SCSI, and iSCSI storage. If you plan to use SCSI or iSCSI, you must configure it to be presented as block-level storage within the hardware virtualization software, and it must be dedicated to the Exchange guest machine. Exchange 2007 does not support the use of network attached storage, but if the storage is attached at the host level, the guest will see it as local storage. Should you plan to use SCSI or iSCSI in your virtual Exchange environment, Hyper-V only supports VHDs up to 2040 gigabytes (GB) in size, and virtual IDE drives up to 127 GB; plan accordingly.

- Microsoft supports the use of both cluster continuous replication (CCR) and single copy clusters (SCC) within Exchange running in a virtual environment so long as there are no hypervisor-based clustering or migration technologies in use. An example of these technologies would be Quick Migration for Hyper-V and VMotion for VMWare. Likewise, Microsoft does support the use of hypervisor clustering and migration so long as CCR and SCC are not in use within the Exchange environment.

- One of the biggest advantages of virtualization is the ability to take snapshots of your virtual environment as part of a backup or disaster recovery plan. In the Exchange world this can be problematic because this kind of technology is not “application aware.” This means the snapshot technology is not capable of taking into account the way the application actually uses and processes its data. Because of the way Exchange processes data, Microsoft does not support the use of any kind of snapshot technology with your virtual Exchange server. However, it should be noted that in the case of Exchange, the other benefits of virtualization tend to outweigh the inability to use snapshot technology.

- When you are configuring the virtual processors for your Exchange host, it is important to understand that Exchange running in a virtual environment does not support a ratio of greater than 2:1. Hypervisors provide the ability to share the logical processors of the host server to the guest machines. For example, a dual processor system using quad core processors contains a total of eight logical processors in the host. You may have some virtual servers that end up using less processor power than another, so the full processor may not be needed by that server. Depending on the virtual servers, this may allow you to have much more than eight virtual servers configured to have two processors each. However, in the Exchange world, Microsoft would not support the allocation of more than 16 virtual processors across all of the guest machines running on the server, or a total of four quad processor Exchange servers.

Source of Information : Elsevier-Microsoft Virtualization Master Microsoft Server Desktop Application and Presentation

Friday, December 23, 2011

Static versus Dynamic Languages

One of the great debates among programmers is about static versus dynamic languages. It’s a debate that will go on forever because both sides have good points. The basic difference has to do with when errors are detected. In a dynamic language, errors aren’t caught until the bad code is executed. For example, in a dynamic language like Python, if you write a method call like x.foo(), and x doesn’t have a “foo” method, you won’t get an error message until that statement actually executes. In a static language, you need to declare types for things. Then, using the information provided by those declarations, errors like the undefined method in the example above can be caught at compile time.

It’s a trade-off: in dynamic languages, you don’t need to write type declarations to prove to the compiler that your program is correct. That’s very convenient, and it can lead to a style of programming in which your code is much simpler—and simpler code is less likely to have hard-to-find errors.

On the other hand, static languages catch a lot of mistakes for you. They force you to be more rigorous about how you write your code in order to make sure that it passes the compiler, and that process causes you to produce better-designed code.

Personally, I fall on the static language side of things. I find that the extra work of dealing with the type system saves me a huge amount of effort in the long run. Most of the silly mistakes that I make get caught by the compiler and never cause problems at runtime. In fact, my own preference is for very strongly typed languages, like the functional language ML. ML’s type system is incredibly expressive and incredibly strict, much more so than more familiar static languages like Java and C++. But in return, my ML programs almost never have runtime errors. Nearly all of the mistakes that I make end up getting reflected as inconsistencies in types. I’ve written thousand-line programs in ML and had them work without a single error on the first run after spending days working with the compiler to get rid of the statically detected type errors.

Source of Information : Pragmatic - Code in the Cloud Programming Google App Engine 2011

Wednesday, December 14, 2011

HTTP Status Codes

The HTTP standard has an extensive list of status codes for server result messages. These are the ones you’ll encounter the most:

200 OK. The request was completed successfully. The body of the message will contain the result of the successful request.

301 Moved permanently. The requested has been permanently moved, and this and all future requests for the resource should be sent to the new location.

303 See other. For this request, the result can be found by doing a GET on a different URL. The URL can be found in the Location header of the message. This is generally used for the result of PUT requests, where after the PUT was successfully processed, the server tells the client where to look to see the result of the operation.

401 Unauthorized. The request was valid, but the user has not provided any authentication data to show that he or she should be permitted to see the resource. The user could use some other request to get an authentication code and then retry the request.

403 Forbidden. The request was valid, but the user is not allowed to access the specified resource. This is similar to 401 but indicates that either the user has been authenticated and still can’t access the resource or that even if the user was authenticated, that user is not permitted to access it.

404 Not found. No resource was found at the specified location.

500 Internal Server Error. Any error in the server during its processing of the request will end up generating a 500 error. In particular, for App Engine services that you implement, the client browser will receive a 500 when your request handlers crash and/or throw an exception.

501 Not implemented. The request wants to perform some operation that the server doesn’t support. You’ll see this most often if you do something like misspell the URL in a POST request.

Source of Information : Pragmatic - Code in the Cloud Programming Google App Engine 2011

Thursday, December 8, 2011

Why Start with Python?

I’ll say more about this later, but I’m not a huge Python fan. We’r e starting with it first for a few reasons. First, Python is a very pleasant language that makes it possible to do a lot with a small amount of code. We can start writing Google App Engine programs with just a few lines of code. There’s very little in the way of required infrastructure. When you’re learning how to develop for the cloud, Python is great way to start.

Second, my tastes shouldn’t dictate how you should build your application. Python is a very powerful, flexible language, and it’s got excellent support in Google App Engine. If you’re a Python aficionado, then after reading this book, you should be able to build your App Engine applications in Python.

Third, we’re going to learn tools like GWT, which generate a lot of code for us, taking care of the underlying mechanisms of the client/server interaction in our cloud applications. For developing complicated applications, that saves us incredible amounts of effort. But it’s important to understand what’s happening behind the scenes.

Python gives us a good way of exploring the primitive infrastructure of a cloud application. We’ll be able to look at each piece of technology, build it up, and learn about how it works. When we get to GWT, it will be easy to understand what’s really going on.

If you decide you like doing your cloud programming in Python, you’ll learn enough to be able to do it. But even if you never write a cloud app using Python, taking the time to explore the basic technologies of cloud applications using Python will help you understand and debug your real applications in whatever language you decide to use.

Source of Information : Pragmatic - Code in the Cloud Programming Google App Engine 2011