Windows Azure uses a must-read

Original: http://www.cnblogs.com/dyllove98/archive/2013/06/15/3137528.html

In recent days, I've helped a lot of users migrate to Windows Azure, and in the process, I've discovered that users are not very good with azure, because they're not familiar with Azure technology and are unfamiliar with the ideas that Azure is advocating. For the public cloud or for new users of azure, learning must be a process, which is not a big problem. However, some problems must be understood before the actual deployment, or inadvertently lead to data loss, system downtime is not worth the candle

1. [Account] Find out the subscription for each app and the quota, billing method, expiration date of the subscription

In azure, users need to differentiate between accounts and subscriptions. The account (live ID) is used to login to the portal, corresponding to a natural person. Instead, subscriptions correspond to quotas, billing, and payment information. This is like a person has an identity card (account), but can have multiple mobile phone number (each mobile phone number independent accounting). The same azure account can have multiple subscriptions, and each time you deploy an azure virtual machine or other service, you choose a subscription. Each subscription has a primary administrator who can add other users as users of that subscription. These added users can share the subscription resource and are suitable for scenarios developed by the project team. All Subscribers to the subscription have the same permissions, the only difference being that only the primary administrator can access the accounting information.

On the portal, users can also filter out unrelated subscriptions

Because each subscription is different, it is necessary to understand these subscription information before deployment:

• What is the type of subscription, a trial, MSDN, pay-as-you-follow, or multi-month plan?
• The validity period of the subscription
• Does the subscription have quotas? If so, you need to check the remaining quota periodically to avoid subscription deactivation
• Does the subscription exist for other users and will they mistakenly manipulate the apps I deployed?

Among them, it is most important to understand the validity period. if the subscription expires, it may cause all data to be emptied

2. [Virtual machines and cloud services] Be sure to distinguish between BLOB disks and temporary disks

There are two types of disks on a virtual machine on azure, one stored on BLOB storage and one stored on the physical machine disk on which the virtual machine resides. The former due to the use of BLOB storage, its data will be stored locally according to the BLOB Storage Policy 3 copies, and maintain a mirror offsite, the availability and reliability of the data is very high, the virtual machine access to these BLOB storage over the network, do not rely on a specific physical machine. The latter depends on the physical machine, and if the physical machine fails or is maintained, the storage may be emptied. Obviously, if we use the virtual machine without knowing the type of the disk, it will result in data loss.

The types of disks for different types of azure virtual machines are as follows:

• IaaS Windows virtual machine: C-Drive (System disk) is a BLOB disk, D-Disk is a temporary disk
• IaaS Linux Disk: sda1 (root directory) is a BLOB disk, SDB1 (/mnt/resource) is a temporary disk

• Virtual machine disks for PAAs Cloud services: c/d/e are all temporary disks.

Never put important data such as database table files on a temporary disk!

These temporary disks tend to be quite large, and it's a pity to use them altogether. In addition, the temporary disk is local and the data is accessed faster than the BLOB. Therefore, the temporary disk is suitable for storing some temporary data, such as bare log, intermediate result, upload download cache, etc.

So, if the program to store files locally, the local system disk space is not enough, what to do?

• For an IaaS virtual machine, you can click "Attach empty Disk" from the virtual machine page of the Azure portal, which will allocate an empty BLOB disk and hook it up on the virtual machine. The created disk can also be detached from the original virtual machine and then hooked up to another virtual machine. One disk cannot be attached to two virtual machines at the same time.

• For cloud service virtual machines, it is not recommended to store the files on the local file system, but instead to store the files directly on the blob, you need to modify the file access API. If you do not want to modify the code, there are two ways:
  
  • If your application needs to read some local files, or if you need to install some software on the virtual machine, you can include the file download and the software installation commands in the cloud service startup script, refer to http://blog.csdn.net/shaunfang/article/details/ 8939681 If you manually install software or copy files to a cloud service virtual machine, all changes will disappear after the virtual machine restarts.
  • If your app not only reads files but also writes files, you can't use the method above, but you must use Azure drive. It is a way to mount a BLOB disk on a virtual machine, and you can refer to http://blogs.msdn.com/b/azchina/archive/2010/04/12/windows-azure-windows-azure-drive.aspx. It is not recommended because it does not conform to the concept of PAAs. An important feature of cloud services is the ability to expand and delete nodes quickly and easily. If you use drive, you need to bind a drive for each virtual machine so that you can maintain the drive itself, as well as the corresponding relationship between the and virtual machines. Instead of using it this way, it's better to use IaaS directly

3. [Website, cloud service and virtual machine] understand the mechanism of load balancing

Azure provides free load balancing for websites, cloud services, and virtual machines. What we need to pay attention to about load balancing is its handling of the session. In general, the traditional load balancer has a mechanism called session sticky (sticky), that is, according to the user's session information to forward the user request to a fixed machine, so that if the application on the server side store session information, Then the user interacts with the server will be smooth, otherwise, the user session is lost and the application of logical exceptions

On azure, the load balancer for cloud services and virtual machines is purely network-level, and its equalization mechanism is to rotate the request to the backend server without supporting session stickiness. This requires the background server is stateless, that is, regardless of the customer request to any one server, can be processed correctly. If the existing application is stateful, there are two workarounds:

1. The session information is shared among all servers. Implementation methods include: Distributed cache (such as Memcache,azure Caching), Session persistence (. NET and Java both support the use of databases to store session information, while Azure also supports persisting. NET session information with cache and Azure storage: http://blogs.msdn.com/b/cie/archive/2013/05 /17/session-state-management-in-windows-azure-web-roles.aspx)
2. Configure your own load Balancing cluster on a virtual machine, such as squid (Linux), IIS ARR (Windows). Microsoft's Msopentech team provides a way to automatically configure IIS arr: https://github.com/MSOpenTech/WindowsAzureToolkitForEclipseWithJava/tree/ Master/utils/arrconfigurationagent. It was originally intended to configure the Java cluster within the cloud service, or it could be used to configure other IIS clusters

The Web service has a slightly different load balancer, and its load balancing is implemented by IIS arr, so it natively supports session sticky. The implementation principle is to add arraffinity this cookie in each response, so that the next time the same user's request is identified and sent to the last server. That is, regardless of whether the app is actively writing cookies or accessing Session,iis, it maintains the server's binding relationship for each user.

4. [Architecture and Operations] any service may be down

Although Azure's architectural design takes full redundancy into account, it is still possible to stop, which is something that no service can avoid. Even 5 9 availability will have a window for downtime. The cause of downtime may be non-human factors, such as disconnection, power outages, hardware failures and so on, may also be artificially planned downtime maintenance. As a result, as a user, you need to be aware of possible risks and solutions as you deploy your application to the cloud platform. Azure as a platform, or a cloud operating system, will try to do without downtime, but this is only platform-level. From an application perspective, users also have to consider whether Azure provides availability that meets business needs, and if not, how to design to improve the overall usability of the application. Most of the time, higher availability means higher costs, so it 's unrealistic to pursue 0 outages, and Azure can't do that . Developers must be prepared in advance.

Regarding the availability of azure, developers and OPS need to know in advance:

• The services provided by Azure are independent, and services generally do not affect each other. For example, the database service is not affected when the virtual machine service fails in its entirety. Users can log on to the availability monitor at any time to see the availability of each azure service in each region http://www.windowsazure.com/en-us/support/service-dashboard/
• Azure provides an independent SLA commitment for each service, with the vast majority of the promised availability metrics of 99.95%, which means a maximum of 4.38 hours of service disruption per year, and Azure will compensate if exceeded.
• The availability commitment of virtual machines and cloud services is special. The promise of a virtual machine service is that the overall availability of a cluster of 2 VMS is 99.95%, and that the two VMs are also within the same availability set (http://www.windowsazure.com/en-us/manage/windows/ common-tasks/manage-vm-availability/), and the promise of cloud services is that each role requires at least 2 instances, and the availability of each role is 99.95%. Never deploy only one virtual machine within a role, so the probability of downtime is high. Azure has a monthly upgrade of the physical machine OS and cloud service virtual machine OS, and each upgrade can cause cloud services to stop service for single-instance cloud services.

As can be seen, Azure does not provide a service commitment for single-instance virtual machines. If you want to deploy a database on a virtual machine, such as MySQL, you need to configure HA yourself and set two VMs to the same availability group, so that Azure will place the two VMs in different fault domains (for example, different racks)

In addition, when you deploy a service, you can draw a logical topology, such as the Azure service that you use. Then analyze the possible impact of outages on different services, and then analyze how to deal with a service outage or failure.

If you want to understand best practices for high-availability design under cloud computing architecture, you can refer to the following:

Failsafe: A guide to Resilient cloud architectures

http://msdn.microsoft.com/zh-cn/library/jj853352

5. [Operation] Good data backup

Data backup is a cliché, it is a core of operation and maintenance work. Although Windows Azure provides a complete data storage solution, such as a copy of the data stored locally three copies, support offsite data mirroring, etc., but this only solves the problem of physical damage to the data, but does not solve the problem of logical corruption. For example, a maintainer accidentally deletes a file on a blob, deletes a program bug, or modifies data content. Therefore, it is necessary to make a backup of the data in the cloud . Specifically, each type of data is backed up differently.

• SQL database. The Azure portal provides backup functionality for SQL databases, and users click the Backup button to export the database content to blob storage in the Format data Tier application. Users can download the backup file to import to a local SQL Server, or you can use the file to recover a SQL database. For SQL databases, it is recommended to use automated scripts for regular backups, such as once a day for 7 days. SQL database does not support recurring tasks, and we can run periodic scripts with Windows Task Scheduler or Linux cron. Specific commands can refer to the Https://github.com/richorama/SQLDatabaseBackup
• Blob storage. The BLOB store itself does not provide backup functionality and can only take snapshots. Snapshots can roll back files to previous versions, but cannot recover deleted files (Azure does not support container snapshots). Therefore, for important files, it is recommended to write a script for regular backups. The destination address of the backup, which can be another storage account, or local. Azcopy This tool can be used to copy files between different storage accounts or to transfer files between local and Blob http://blogs.msdn.com/b/windowsazurestorage/archive/2013/04/ 01/azcopy-using-cross-account-copy-blob.aspx
• IaaS virtual machines. The currently available method is to take a snapshot of the Blob file corresponding to the virtual machine disk. Refer to Http://blog.csdn.net/shaunfang/article/details/8933405#t0 for details
• IaaS Virtual machine files. You can use a variety of traditional file backup tools. For Windows Server, you can use Azure's cloud backup service http://blog.csdn.net/shaunfang/article/details/8933405#t1
• Databases in an IaaS virtual machine. can use a variety of database backup tools or export the database and file backup

Backup of all the above data is done on a regular basis, it is recommended to write a program or script, specifically to find a virtual machine to run

Windows Azure uses required read (GO)