Posterous theme by Cory Watilo

Filed under: Cloud

Amazon Web Services keep getting better!

A few months ago I wrote about the issues with "destructive" instances when dealing with Active Directory. So I was pleased to see the recent announcement on the ability to boot from an EBS image. Boot from EBS This is one of the newest features they announced in December that I think really brings them in parity with other IAAS offerings out there today.  December was actually a busy month for AWS with several interesting announcements including: Elastic Load Balancing - A simple load balancing solution that eliminates the need for software based solutions Northern California Region - A great addition to the rock solid East Coast and European regions. They also announced they'd be opening an Asia Pacific region in the first half of 2010, which will give them a great global presence. Support for Window 2008 Instances With Microsoft Azure coming onto the market soon, it will be interesting to watch as Amazon continues to innovate and as the cloud market starts to look at leverage azure and numerous other cloud startups.

Microsoft Active Directory and EC2

On September 30th, Amazon announced they would no longer charge a higher per hour fee for Windows servers utilizing authentication services. The new pricing makes windows on EC2 a lot more attractive then it had been previously. The differentation between windows and windows with authentication services was always an agitation previously.
The new pricing is great, but i've been doing a lot of research and experimentation with running a domain on Amazon EC2. Running a domain on EC2 is more complicated then it should be, and requires a lot more due dilligence and scripting of your windows instances to successfully work in the domain structure.
Setting up a windows domain is a straightforward process that any MCSE should be able to accomplish. A WIndows 2003/2008 server can be turned into a domain controller by running the DCpromo utility and following a simple wizard. Of course you need to make sure you properly size your AD sysvol and place it on the D: drive of the server.
Once the domain is configured and setup, it starts to get tricky and overly complex. There was an aritlce on Amazons developer site that detailed some of the backup and DR practices you, but it seems to have been pulled. I've linked to a cached copy, but will keep checking back in case they republish or update the article.
http://74.125.155.132/search?q=cache:CqMDdqzir20J:developer.amazonwebservices.com/connect/entry.jspa%3FexternalID%3D2435+Creating+an+Active+Directory+Domain+in+Amazon+EC2&cd=1&hl=en&ct=clnk&gl=us
As you can see from the document they state that you need to ensure that you have solid backups of your Active Directory environment. Ideally you'd want to store these backups on S3, persistent drive or a server in your local environment. They also advise that you must always have two domain controllers running in the event that an instance becomes degraded.
If your primary domain controller becomes corrupted you deploy another server, run dcpromo and add the new server to the domain structure. They do neglect to mention that if you were to take this approach you need to take careful care to monitor your FSMO roles, DNS server configuration/status and also ensure your global catalog is fully replicated to all domain servers.  Also when an old instance has terminated you will need to make sure you remove the domain controller from the AD structure so you don't attempt to replicate accounts and objects to a server that no longer exists.
A normal windows/linux instance can be created, configured and setup and then you can follow the document to create an AMI image of the server that you can reuse to deploy identical images. Unfortunately part of the point of an AMI is that these servers are unique and in a windows world the deployment process resets the GUID. Because of this you can't just setup 3 or 4 servers with images to to be your domain controller as they woudn't function as a domain when they were brought online.
The other large problem you have to deal with is the DNS server, having multiple DNS servers that may or may not exist will require quite a bit of maintenance activity making sure each domain controller has DNS, that the records are being purged correctly, and that your client machines are pointing to a static IP mapping that you can move from server to server.
Not only do you have this increased complexity with the domain controllers and DNS your windows instance that run your databases, applications, etc will also need some additional tweaking to work properly. You'll need to create scripts that add the instances to the domain as the instance is initiated, this will allow the instance to be part of the domain and leverage domain policies and accounts. As instances can be a temporary item, you'll also need to make sure you regularly purge old instances from the Domain and DNS records.  This additional scripting and processes require extra time and testing in building your AMI images.
The advice given by amazon and all of these best practices are great, but I do recall issues when EC2 was still in beta with the entire EC2 cloud needing to be restarted. This results in the need to start all brand new instances, and you may not have the luxury of a previous domain controller to ensure your domain structures. This means you'll be restoring your AD infrastructure from your backups.
Utlimately, the fault here doesn't lie in Amazons systems, but really the whole domain concept that Microsoft has built. Its not a very cloud ready service, relying heavily on SMB traffic and local networks. Ideally an active directory design that leverages native TCP/IP, easy domain memberships and the ability to be started off an AMI would be a huge improvement ot the current AD structure.  In a perfect world though, I'd actually prefer to leverage Active Directory as a service from a SaaS provider or managed services vendor that I could leverage in Amazon or any cloud provider.
I'd love to get feedback on what others are doing to solve these WinAD problesm in the cloud. I'm planning on doing some further research around Read Only Domain Controllers, Federated Domain services and ADAM (Active Directory Application Mode) as they may be better solutions in the long term for what i'm working on accomplishing.
On September 30th, Amazon announced they would no longer charge a higher per hour fee for Windows servers utilizing authentication services. The new pricing makes windows on EC2 a lot more attractive then it had been previously. The differentation between windows and windows with authentication services was always an agitation previously. The new pricing is great, but i've been doing a lot of research and experimentation with running a domain on Amazon EC2. Running a domain on EC2 is more complicated then it should be, and requires a lot more due dilligence and scripting of your windows instances to successfully work in the domain structure. Setting up a windows domain is a straightforward process that any MCSE should be able to accomplish. A WIndows 2003/2008 server can be turned into a domain controller by running the DCpromo utility and following a simple wizard. Of course you need to make sure you properly size your AD sysvol and place it on the D: drive of the server. Once the domain is configured and setup, it starts to get tricky and overly complex. There was an aritlce on Amazons developer site that detailed some of the backup and DR practices you, but it seems to have been pulled. I've linked to a cached copy, but will keep checking back in case they republish or update the article. Active Directory on Amazon EC2 As you can see from the document they state that you need to ensure that you have solid backups of your Active Directory environment. Ideally you'd want to store these backups on S3, persistent drive or a server in your local environment. They also advise that you must always have two domain controllers running in the event that an instance becomes degraded. If your primary domain controller becomes corrupted you deploy another server, run dcpromo and add the new server to the domain structure. They do neglect to mention that if you were to take this approach you need to take careful care to monitor your FSMO roles, DNS server configuration/status and also ensure your global catalog is fully replicated to all domain servers.  Also when an old instance has terminated you will need to make sure you remove the domain controller from the AD structure so you don't attempt to replicate accounts and objects to a server that no longer exists. A normal windows/linux instance can be created, configured and setup and then you can follow the document to create an AMI image of the server that you can reuse to deploy identical images. Unfortunately part of the point of an AMI is that these servers are unique and in a windows world the deployment process resets the GUID. Because of this you can't just setup 3 or 4 servers with images to to be your domain controller as they woudn't function as a domain when they were brought online. The other large problem you have to deal with is the DNS server, having multiple DNS servers that may or may not exist will require quite a bit of maintenance activity making sure each domain controller has DNS, that the records are being purged correctly, and that your client machines are pointing to a static IP mapping that you can move from server to server. Not only do you have this increased complexity with the domain controllers and DNS your windows instance that run your databases, applications, etc will also need some additional tweaking to work properly. You'll need to create scripts that add the instances to the domain as the instance is initiated, this will allow the instance to be part of the domain and leverage domain policies and accounts. As instances can be a temporary item, you'll also need to make sure you regularly purge old instances from the Domain and DNS records.  This additional scripting and processes require extra time and testing in building your AMI images. The advice given by amazon and all of these best practices are great, but I do recall issues when EC2 was still in beta with the entire EC2 cloud needing to be restarted. This results in the need to start all brand new instances, and you may not have the luxury of a previous domain controller to ensure your domain structures. This means you'll be restoring your AD infrastructure from your backups. Utlimately, the fault here doesn't lie in Amazons systems, but really the whole domain concept that Microsoft has built. Its not a very cloud ready service, relying heavily on SMB traffic and local networks. Ideally an active directory design that leverages native TCP/IP, easy domain memberships and the ability to be started off an AMI would be a huge improvement ot the current AD structure.  In a perfect world though, I'd actually prefer to leverage Active Directory as a service from a SaaS provider or managed services vendor that I could leverage in Amazon or any cloud provider. I'd love to get feedback on what others are doing to solve these WinAD problesm in the cloud. I'm planning on doing some further research around Read Only Domain Controllers, Federated Domain services and ADAM (Active Directory Application Mode) as they may be better solutions in the long term for what i'm working on accomplishing.

Amazon AWS

I was initially intrigued by cloud computing when Amazon started supporting windows servers on their EC2 compute environment. I was excited about the possibility of having a lot of flexibility with Amazon’s services but also not having to deal with Linux all the time was appealing.  (Ironically, considering i chose slicehost and this blog is on ubuntu… this wasn’t as important as I originally had thought).  While the overall signup for AWS was easy, I was immediately presented with a lot of technical concepts I wasn’t familiar with. Published and private AMI’s, multiple directories of images, and really was lost for the first day as I tried to make sense of it all by reading the Amazon documentation.  I realized very quickly that this wasn’t going to be as easy as I had initially thought it would be.  Having a full time job that isn’t overly interested in looking at Amazon right now, this meant a large amount of time spent outside of work, something that made the wife less then happy. Luckily there are some really great 3rd party tools, and before I finally bailed on Amazon they did release their own control panel to help with the management of their cloud infrastructure.  However, their tools still pailed in comparison to the third party software. Rightscale- Rightscale made my life much easier immediately, instead of attempting to manage several key pairs (passwords are stored in encrypted key pairs, and API calls utilize these keys as well). Rightscale offered a web interface that easily handled the heavy lifting of dealing with the amazon API’s.  I was very easily able to figure out how to deploy an AMI for a linux host on rightscale, and their overall management capabilities were a welcome friend for this Windows guy. However, there was one issue since Amazon had just started supporting Windows, rightscale was just starting to develop their additional windows management tools. ElasticFox- ElasticFox is actually a plug in developed by Amazon to help you manage your Amazon instances, it was not as easy as Rightscale but overall provided a lot of value and following the directions at scripting.com I was able to easily setup my first windows instance on the Amazon’s cloud.  Luckily for all of you who are going to try this now, David Winer has created a very simple step by step guide that is very helpful. http://howto.opml.org/dave/ec2/ I’m still no expert with the Amazon EC2, although I haven’t completely given up, the largest reason I chose not to use it for hosting the blog was cost.  $0.125 per hour for a small windows instance, doing some back of the paper math, if I assumed 31 days x 24 hours a day it came out to roughly $93.00 dollars + the data and storage costs. For these costs it didn’t make it economical for me to host my personal blog on amazon's cloud and how I ended up checking out Slicehost for $20.00 dollars a month.  Ultimately, the $73.00 dollars it saves me per month is well worth the small extra hassle for dealing with ubuntu, which really isn’t all that bad, having dabbled long enough in the linux world I know my way around apache and Mysql. I’m not done with Amazon yet, but for hosting my personal blog, its not the right solution. I’ve seen several blog posts about the pricing for Amazon as well, and the use cases that it makes sense seem to be around either temporary processing compute needs or if your hosting a site that will end up on digg at any moment and your usage will go from 100 users to millions in a few hours. While I can dream that will happen with this blog, I’m going to be realistic and hedge my bet that its not the case, and the burstable capacity offered by Amazon just isn’t needed right now.

Experiments with Cloud Computing

I've wanted to setup my own blog for quite a while to rant and rave about all things SaaS, Cloud, Infrastructure and IT Operations related.  I've been playing with different options to host a solution, from converting an old HP desktop into a small linux server to looking at cloud options. The process has been quite entertaining as the current implementation of cloud computing is more complicated then it really should be. If it wasn't for numerous blogs and how to's, i'm not sure I ever would have figured out my way around Amazon's elastic compute cloud. I'll detail each of the solutions I tried in a future post, but my final choice ended up being slicehost.  I'm incredibly impressed how fast even my small instance runs so far, with lightning fast downloads and fantastic performance of this application. It also provided some unique features that I didn't see with Amazon, and the pricing was much cheaper then amazon. If you can manage a linux system (as windows isn't available today on slicehost), I would highly recommend it. I'm also really pleased with Wordpress for this blog, it was incredibly easy to setup on top of LAMP. I'm not happy with the overall theme yet, but for a project I started this afternoon and about 4 hours total, i'm very happy with how far I have gotten. Stay tuned for future posts.