***non-techie - personal post***
For those who don't know, I recently joined Microsoft and work on the World Wide Windows Azure Centre of Excellence team - a small team of highly skilled technical people, many of which have been at Microsoft for a number of years in different organisations. We are known internally as "Azure COE".
The team is based out of Redmond, WA but I live in the UK and my responsibility is the EMEA region but no doubt, I will get involved in other regions as well once I get settled in. This is no doubt the best job I have ever had, I know it is early days but that is my feeling right now. I am no longer billable, so my responsibilities are to help customers, internal employees and partners be successful in deploying Windows Azure as a technology solution from an architectural and technology perspective.
It is up to me to define what I will take ownership of, this truly excites me. I will take a few weeks to determine gaps, strategic direction and areas where I can focus more of my time and this is what I find the best thing about this role.
It is also a very exciting time for anyone in our industry to be involved in cloud computing. Everyone that is, ISV's, SI's (System Integrator's), CIO's, CTO's should at least consider a cloud platform as a tool to be used in the vast tool set for any business problem that can be solved using technology today. It might not be the correct technology to use in all cases but it should be considered like any other.
My first day, I arrived in Reading, Thames Valley Park, UK (known as Microsoft UK). I was quite tired when I arrived after a 3.5 hr drive due to the M25 London orbital motorway (known here as the car-park) being congested as ever. I actually found myself watching BBC News 24 on my Samsung Galaxy S2 device while parked up on the motorway! It saved me from extreme boredom.
After checking-in, I met up with Tim Furnell who was acting as "host manager" to bed me into Microsoft nicely. Tim did a good job of getting all the things I needed and getting connected to corp net.
The next day I worked from home and did a lot of NDA stuff that I can't talk about but you will eventually hear about in the future. This is another cool thing about the job. I get to hear about, work-on technology before it's even announced publicly. This enables me to make better decisions for our customers and to be more well informed in what's coming. I also get to address what is known as "whitespace" areas which are gaps in Microsoft products.
That's another thing they love here - home-working, office-working, coffee-shop wherever, it doesn't matter where you work so long as you get your work done. Not a 9-5 person? - doesn't matter! They promote the use of on-line conference calls all the time. I have calls pretty much every day over Lync (internal VoIP).
Then the next two days I spent time with my colleague Dennis Mulder from the Netherlands. After these two days my head was rather full of information. You don't realize just how big and how much information is at your finger-tips until you work here.
Think of the biggest library you have ever set foot-in, multiply it by about 1000 then you might come close to the vast quantity of information available here at Microsoft.
Microsoft are very supportive in pretty much every area you can think of. But the most important to me is learning, they totally promote it. You'd think this would be the same for all companies, but many other companies are interested in your billable time first and foremost and not you as an individual and your aspirations and career goals.
I'm also finding everything highly efficient and smooth running. It's because everything is automated - where it can be. Example, applying for a AMEX corp card, I applied using //... (DNS) is used for everything there is a name for everything i.e. //training //sqlsvr etc... then after applying, the next day the card turned up!
Booking travel, hotels, cars is automated and billed to your cost centre to reduce admin expense claims. So far the next 3 months will be fairly busy and a bit of international travel for some really interesting events.
Dennis and I will be running the Tech Ed 2012 EMEA Pre-Conference Azure bootcamp workshop in June, so if you're going we'll see you there!
And finally, if you're from Microsoft reading this and need the Azure CoE's help within EMEA, ping me internally (note we are free - non-UBI).
Saturday, April 28, 2012
Saturday, April 14, 2012
SQL Server setup does not support the language of the OS or does not have ENU localized files
I encountered a very strange error this morning when attempting to install Microsoft SQL Server R2 EN Standard Edition from my file server which I have successfully done many times before - mainly from VM's.
Today, when I attempted to run the SQL installer on a fairly new Windows 7 EN OS physical machine, I got the following error:
After reading about this problem on Connect here: http://connect.microsoft.com/SQLServer/feedback/details/556958/sql-server-setup-media-does-not-support-the-language-of-the-os
I tried some of the workarounds mentioned on Connect above, none worked. So as my machine is a dev machine, I'm happy to put the developer edition on which doesn't appear to be localized?!?
But before doing this I really wanted to figure out why I was getting this problem. I am running an English version of Windows that is set to the United Kingdom as the locale. Why is this not working for me!?
So then as I was attempting to install from a network file server, I thought I'd burn to disc and then try it from a DVD. So I fired up Windows 7 USB/DVD Download Tool (get the code from here: http://wudt.codeplex.com/). Ran it and I got this error:
So this is really weird as I have installed SQL Server from that ISO before (at least I think I have).
So in the end I downloaded a new fresh copy of SQL Server, ran it from the network server and it worked! So this error for me was a red hearing.
Tuesday, April 03, 2012
Windows Azure Traffic Manager to handle your public cloud DR strategy
I did a talk last month at the Windows Azure User Group in London. To be honest I had too much content to get through and part of my talk was to talk about drastic recovery otherwise known as disaster recovery (DR). I ran out of time and didn't get a chance to talk about it unfortunately.
What is Drastic (Disaster) Recovery
Some people say DR is not possible or difficult to implement in a Cloud Platform such as the PaaS model. This is in contrast to Cloud Platform IaaS as you have more control over hardware/configuration in a IaaS environment than you do in PaaS. But hopefully after you have read this article, you'll soon realise it is very easy now in Windows Azure.
For people not aware of DR, I'll explain it using a picture that illustrates the problem when using Windows Azure, consider figure 1 below:
In the above diagram we have some roles running in a Windows Azure data centre in both Europe and North Central US and a consumer that is consuming from 1 data centre, Europe.
The configuration depicted above is known as a failover or active/passive configuration which is very commonly found in drastic recovery configurations in the enterprise today. If the above were a private data centre whether this is private cloud or a traditional data centre, it would look almost identical.
When you deploy an application in an Azure data centre, you can't spread it across multiple data centres for resiliance or to implement DR. Well you can but you'll get a different URL for each data centre you deploy your application into. For example for the Europe data centre above, our full URL could be: http://myamazingapp-europe.cloudapp.net/
Then for the North Central US data centre, the URL has to be something different like: http://myamazingapp-us.cloudapp.net/
Because we have two different URL's this leads us to a problem because if the Europe data centre goes down, which in the above case is our active configuration, the users will not be able to use the application which affects availability unless the active configuration becomes the DR environment which is the USA data centre.
This means the Europe data centre is currently serving up the users requests all the time and the USA data centre is in passive/sleep state - in other words not being used unless of a failure in the Europe data centre. When/if this failure occurs, we need to switch from Europe to the USA data centre. This is not easy with the current configuration because the users/actors will have to switch URLs from Europe to the USA data centre - this is far from ideal as often the user/actor probably wouldn't know when to try the other URL, it really needs to be seamless.
So we really want to use a single URL that has the ability to reference both data centres when we need to without the users actually knowing.
A simple way to implement DR in Windows Azure
This is where DNS (Domain Name Service) play a very important role in hardware infrastructure and helps us solve this problem relatively easilly.
Now consider an amendment to the above diagram (figure 1) to now abstract the user from the *.cloudapp.net domain name using a internet DNS registrar and a CNAME record that resolves to the Azure data centre required. Remember, each cloudapp sub domain represents a single data centre region. When you design for a drastic recovery solution, you wouldn't normally use the same data centre as it kind of defeats the purpose of having a DR strategy.
With the amendment above, we can give url: http://myamazingapp.com to end users/actors. They are now completely unaware of where their application is being served up - which is how it should be.
Of course they could run a trace (TRACERT) on http://myamazingapp.com and see where it resolves to. In fact, I have made the above configuration on a application I have deployed in Azure right now. If I run TRACERT on my sub domain: http://remotemedia.simonrhart.com I get the following:
You can see from the above trace, my subdomain resolves to Microsoft's data centre DNS http://remotemedia.cloudapp.net IP address: 94.245.89.251.
We know that IP address is a real Azure data centre as it is registered to Microsoft. Here is the result from running a whois on the resolved IP address:
So that is wonderful isn't it? DR and failover problem sorted. Well kindof. It's not perfect as it's very manual. If the European data centre where my application is deployed goes down, I need to know about it so I can tell my DNS registrar to change the CNAME record to point to the application that is deployed in the DR data centre - North Central US.
This means I will have to log into my DNS registrar and change the CNAME when a failure occurs like so:
I don't really want my IT admins having to deal with this as it's expensive and adds complexity. I could automate it but then I'd have to put a load of process in place and write some custom code not to mention I'll need some infrastructure running on-premise (most probably).
Surely there is a better way?
Windows Azure Traffic Manager
Although what I have talked about above will work, it's fairly simple and I have done this for some time. But thankfully there is a better way. Microsoft has made available in Community Technical Preview (CTP) a feature called Windows Azure Traffic Manager.
Unlike the way the beta programmes work in Azure, you can start using the Traffic Manager right away. There is no request to make in order to start using it - as per the beta programme
Windows Azure Traffic Manager can solve you're failover DR strategy without having to touch any DNS server/registrar once it's setup and more. It supports the following:
So Traffic Manager will solve our problem of having to manually update the DNS registrar with the new Azure data centre DNS cloudapp domain name. Great, how do I do it?
Enabling Traffic Manager
To start using Traffic Manager you need to use the Windows Azure Management Portal to create a policy.
To do this navigate to the Windows Azure Management Portal and sign-in: http://windows.azure.com. Then click Virtual Network > Get Started With Traffic Manager.
See figure 5 below:
Notice how this is different from using the beta programmes in Windows Azure. With Traffic Manager you can start using it straight away and right now there is no cost to using it.
Once you click the Get Started with Traffic Manager button, you'll see a dialog box similar to the following popup:
Notice, there is a lab that you can do that covers all this setup of Traffic Manager here: http://msdn.microsoft.com/en-us/gg197529 but I have included here for the bigger picture of what specifically Traffic Manager is designed to solve and how you would solve these problems without it.
I have filled in the policy above as per the original high-level architecture diagram in figure 1 above. Note: DNS names are different from my diagram but the concept and design is the same.
In the above, as mentioned we select Failover as a load-balancing method. We specify Europe (remotemedia) as our primary active configuration and the North Central US (remotemedia-dr) namespace as the failover data centre. This one is our passive configuration, the application is there, deployed and waiting to be used should a failure occur.
Some data here is important, one piece is the DNS time to live (TTL). This is the maximum time users will have to wait until the DNS server gets updated with the new URL should a failure occur. The default is 5 minutes (300 seconds). The other important peice of information is the Traffic Manager DNS Prefix field.
Well, the Traffic Manager DNS Prefix field can be anything we want (so long as it hasn't been used already) as the users will never see it. Later we will reconfigure our DNS registrar to point to this DNS address.
Once I click OK, the policy is then created and it is active in Traffic Manager:
Figure 7 above shows how these policies look in Traffic Manager. There is 1 thing left to do though, and that is to configure our DNS registrar to point our custom DNS to our specified traffic manager policy URL we chose.
Figure 8 above shows our final DNS configuration. So what happened here?
We are simply handing the problem of failover over to Windows Azure. So in the above case, Azure will handle changing the DNS CNAME configuration should a failure occur.
Making Sure Traffic Manager is Working
What we now need to do is test that the Traffic Manager failover feature is working correctly.
If we now run a trace route on our new traffic manager URL it should resolve to the Europe data centre (in my case http://remotemedia.cloudapp.net) - remember I have two data centres 1 in Europe (active) and 1 in North Central US (passive):
So I'm happy with that, Traffic Manager's DNS configuration looks correct to me.
Now I want to force a failure so I can test the failover. This is easy, all I need to do is shutdown the Europe data centre services like so:
Now that my Europe data centre services are not running as per figure 10 above, I'll need to wait the 5 minutes (which is what I configured) before I test the failover.
Once 5 minutes has elapsed, I'll run the same trace route command via a command-prompt like so:
I think this is a success, notice the trace now resolves to our North Central US data centre (my URL: http://remotemedia-dr.cloudapp.net)
Also, if I run the trace one layer out from my custom domain: http://remotemedia.simonrhart.com, I get the expected failover data centre as above [remotemedia-dr.cloudapp.net]:
So now you can see how the actual Traffic Manager DNS that you pick can be anything you want, it doesn't really matter what it is.
How does all this look, consider the new amended high-level architecture diagram in figure 13 below:
Conclusion
What is Drastic (Disaster) Recovery
Some people say DR is not possible or difficult to implement in a Cloud Platform such as the PaaS model. This is in contrast to Cloud Platform IaaS as you have more control over hardware/configuration in a IaaS environment than you do in PaaS. But hopefully after you have read this article, you'll soon realise it is very easy now in Windows Azure.
Figure 1: Basic drastic recovery fail over configuration |
This means the Europe data centre is currently serving up the users requests all the time and the USA data centre is in passive/sleep state - in other words not being used unless of a failure in the Europe data centre. When/if this failure occurs, we need to switch from Europe to the USA data centre. This is not easy with the current configuration because the users/actors will have to switch URLs from Europe to the USA data centre - this is far from ideal as often the user/actor probably wouldn't know when to try the other URL, it really needs to be seamless.
So we really want to use a single URL that has the ability to reference both data centres when we need to without the users actually knowing.
A simple way to implement DR in Windows Azure
This is where DNS (Domain Name Service) play a very important role in hardware infrastructure and helps us solve this problem relatively easilly.
Now consider an amendment to the above diagram (figure 1) to now abstract the user from the *.cloudapp.net domain name using a internet DNS registrar and a CNAME record that resolves to the Azure data centre required. Remember, each cloudapp sub domain represents a single data centre region. When you design for a drastic recovery solution, you wouldn't normally use the same data centre as it kind of defeats the purpose of having a DR strategy.
Figure 2: Basic drastic recovery fail over configuration with DNS |
Of course they could run a trace (TRACERT) on http://myamazingapp.com and see where it resolves to. In fact, I have made the above configuration on a application I have deployed in Azure right now. If I run TRACERT on my sub domain: http://remotemedia.simonrhart.com I get the following:
Figure 3: Running TRACERT on my sample app hosted in Azure |
We know that IP address is a real Azure data centre as it is registered to Microsoft. Here is the result from running a whois on the resolved IP address:
WHOIS information for 94.245.89.251:
[Querying whois.arin.net] [Redirected to whois.ripe.net:43] [Querying whois.ripe.net] [whois.ripe.net] % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered.
% To receive output for a database update, use the "-B" flag.
% Information related to '94.245.64.0 - 94.245.127.255'
inetnum: 94.245.64.0 - 94.245.127.255
descr: Microsoft Limited
org: ORG-MA42-RIPE
netname: UK-MICROSOFT-20081107
country: GB
admin-c: AS9763-RIPE
tech-c: EN603-RIPE
tech-c: BR329-ARIN
status: ALLOCATED PA
mnt-by: RIPE-NCC-HM-MNT
mnt-lower: MICROSOFT-MAINT
mnt-domains: MICROSOFT-MAINT
mnt-routes: MICROSOFT-MAINT
source: RIPE # Filtered
organisation: ORG-MA42-RIPE
org-name: Microsoft Limited
org-type: LIR
address: Microsoft
Darren Norman
One Microsoft Way
WA 98052 Redmond
UNITED STATES
phone: +1 (425) 703 6647
fax-no: +1 425 936 7329
e-mail: danorm@microsoft.com
admin-c: NORM1-RIPE
admin-c: NORM1-RIPE
admin-c: NORM1-RIPE
mnt-ref: MICROSOFT-MAINT
mnt-ref: RIPE-NCC-HM-MNT
mnt-by: RIPE-NCC-HM-MNT
source: RIPE # Filtered
person: Allie Settlemyre
address: Microsoft Limited
address: One Microsoft Way,
address: Redmond, WA 98052
address: USA
phone: +1 (425) 705 0516
phone: +1 (425) 936 7329
e-mail: iprrms@microsoft.com
nic-hdl: AS9763-RIPE
source: RIPE # Filtered
person: Bharat Ranjan
address: Microsoft Corporation
address: Redmond, WA, 98102
address: One Microsoft Way
address: USA
phone: +1 (425) 706 3230
fax-no: +1 (425) 936 7329
nic-hdl: BR329-ARIN
source: RIPE # Filtered
e-mail: bharatr@microsoft.com
person: Edet Nkposong
address: Microsoft, One Microsoft Way,Redmond, WA 98052
address: USA
e-mail: edetn@microsoft.com
phone: +14257071045
nic-hdl: EN603-RIPE
mnt-by: MICROSOFT-MAINT
source: RIPE # Filtered
So that is wonderful isn't it? DR and failover problem sorted. Well kindof. It's not perfect as it's very manual. If the European data centre where my application is deployed goes down, I need to know about it so I can tell my DNS registrar to change the CNAME record to point to the application that is deployed in the DR data centre - North Central US.
This means I will have to log into my DNS registrar and change the CNAME when a failure occurs like so:
Figure 4: Setting up a CNAME record |
Surely there is a better way?
Windows Azure Traffic Manager
Although what I have talked about above will work, it's fairly simple and I have done this for some time. But thankfully there is a better way. Microsoft has made available in Community Technical Preview (CTP) a feature called Windows Azure Traffic Manager.
Unlike the way the beta programmes work in Azure, you can start using the Traffic Manager right away. There is no request to make in order to start using it - as per the beta programme
Windows Azure Traffic Manager can solve you're failover DR strategy without having to touch any DNS server/registrar once it's setup and more. It supports the following:
- Performance – traffic is forwarded to the closest hosted service in terms of network latency
- Round Robin – traffic is distributed equally across all hosted services
- Failover – traffic is sent to a primary service and, if this service goes offline, to the next available service in a list
So Traffic Manager will solve our problem of having to manually update the DNS registrar with the new Azure data centre DNS cloudapp domain name. Great, how do I do it?
Enabling Traffic Manager
To start using Traffic Manager you need to use the Windows Azure Management Portal to create a policy.
To do this navigate to the Windows Azure Management Portal and sign-in: http://windows.azure.com. Then click Virtual Network > Get Started With Traffic Manager.
See figure 5 below:
Figure 5: Getting started with Windows Azure Traffic Manager |
Once you click the Get Started with Traffic Manager button, you'll see a dialog box similar to the following popup:
Figure 6: Creating a Traffic Manager Policy |
Notice, there is a lab that you can do that covers all this setup of Traffic Manager here: http://msdn.microsoft.com/en-us/gg197529 but I have included here for the bigger picture of what specifically Traffic Manager is designed to solve and how you would solve these problems without it.
I have filled in the policy above as per the original high-level architecture diagram in figure 1 above. Note: DNS names are different from my diagram but the concept and design is the same.
Some data here is important, one piece is the DNS time to live (TTL). This is the maximum time users will have to wait until the DNS server gets updated with the new URL should a failure occur. The default is 5 minutes (300 seconds). The other important peice of information is the Traffic Manager DNS Prefix field.
Well, the Traffic Manager DNS Prefix field can be anything we want (so long as it hasn't been used already) as the users will never see it. Later we will reconfigure our DNS registrar to point to this DNS address.
Once I click OK, the policy is then created and it is active in Traffic Manager:
Figure 7: Our policy in traffic manager |
Figure 8: That's it, our DNS configured and never needs to change again! |
We are simply handing the problem of failover over to Windows Azure. So in the above case, Azure will handle changing the DNS CNAME configuration should a failure occur.
Making Sure Traffic Manager is Working
What we now need to do is test that the Traffic Manager failover feature is working correctly.
If we now run a trace route on our new traffic manager URL it should resolve to the Europe data centre (in my case http://remotemedia.cloudapp.net) - remember I have two data centres 1 in Europe (active) and 1 in North Central US (passive):
Figure 9: Tracing traffic manager configuration |
Now I want to force a failure so I can test the failover. This is easy, all I need to do is shutdown the Europe data centre services like so:
Figure 10: Shutting down active node in Windows Azure |
Once 5 minutes has elapsed, I'll run the same trace route command via a command-prompt like so:
Figure 11: Tracing now that Europe services are down |
Also, if I run the trace one layer out from my custom domain: http://remotemedia.simonrhart.com, I get the expected failover data centre as above [remotemedia-dr.cloudapp.net]:
Figure 12: Running a trace route from my custom domain |
How does all this look, consider the new amended high-level architecture diagram in figure 13 below:
Figure 13: Complete high-level architecture diagram using Traffic Manager for DR |
Conclusion
So I think the Windows Azure Traffic Manager is a good solution at solving your Windows Azure failover needs. Checkout the Traffic Manager training lab for a hands-on exercise on how to use it in more detail.
In this article, I have also used a public DNS registrar, but if your users are within a corporate LAN but you want to make use of a public cloud platform like Windows Azure, the same concepts apply to an internal DNS server farm.
In this blog post, I wanted to show how DR can be done in a PaaS model like Windows Azure - hopefully you can see how easy it is with Windows Azure Traffic Manager.
Subscribe to:
Posts (Atom)