I have a workgroup server on Windows Azure. I have used Rackspace before and simply image the server to back it up BUT thats not so easy on Azure as imaging the server deletes it!
My Azure server is used to run an application that uses an SQL Database. I backup the DB off site BUT need ensure I have a strategy for downtime of the server. I have looked into roles and instances but am fuzzy on it and getting lost in the many articles. See below what I have so far BUT I don't want the cost of two servers running for one application so **DOES ANYONE KNOW HOW TO ENSURE AVAILABILITY OF AN AZURE SERVER AND BACKUP THE CONTENTS IN THE EVENT OF A CRASH WITHOUT ftping EVERYTHING OFF SITE?
Azure is georedundant BUT you have to set up your server to avail of this feature
Current Azure setup is that we set up Workgroup servers and license them BUT I am fuzzy on where to go from here.
This is where it gets tricky
The number of per-role instances in a Windows Azure application is controlled by the Instances setting in the configuration (cscfg) file.
Windows Azure Service Configuration Schema http://msdn.microsoft.com/en-us/library/windowsazure/ee758710.aspx
How to Configure the Roles for a Windows Azure Application with Visual Studio http://msdn.microsoft.com/en-us/library/windowsazure/hh369931.aspx
Change the Number of Instances
To improve the performance of your application, you can change the number of instances of a role that are running, based on the number of users or the load expected for a particular role. A separate virtual machine is created for each instance of a role when the application runs in Windows Azure. This will affect the billing for the deployment of this application. For more information about billing, see Windows Azure Billing Basics.
• I will continue to research but if any of you know the answer (how can I easily backup my Azure server docs and data without ftping offsite) please feel free to weigh in!
If all you want is to back up the server, then you could use Recovery Services Vaults. This feature allows you to backup any Azure VM. The backup is a snapshot of the entire server.
You can test your contingency plan by restoring the backup to a new VM.
It depends on what you are trying to backup and scale. A proper cloud architecture should not store or persist data on local Azure servers, since that does not scale. You should be persisiting data to azure table storage, blob storage, SQL db and backup the data from there. Then you can use the APIs to backup anything from a central location.
if you are running something like SQL Server or SharePoint then there are some files peristed on the local VMs that you will need to backup. Luckily, those vhd drives are stored on BLOB storage and can be backed up as well in addition to geo redundant backup.
Related
I am trying to use Azure Migrate to move a VM and database from Openstack based cloud to Azure as a VM and managed database. What will happen after the migration is complete ? Will Azure Migrate automatically remove the VM and the database from the source infrastructure ? Are the source resources retained as they are so that the migration can be cancelled if needed?
You have to clean up the resource on Openstack on your own:
Database - Migrate your data with Database Migration Service
Migrate your data with Database Migration Service
In the Azure portal, follow these steps to create an instance of Azure Database Migration Service, and then to run it to migrate the data in your databases:
Create an instance of Azure Database Migration Service. Choose the pricing tier based on whether you need an online or offline migration.
Create a new migration project. Choose the type of migration you want to perform, either offline or online.
Specify source and target server details, including the authentication information.
Identify the databases. Map the relevant target database on the target server to the source server.
Run and monitor the migration.
Select the Run migration button to start the migration. The migration activity screen will appear.
Track the progress until the process shows as completed.
After all the required databases are migrated, check them to make sure they're working.
When these steps are complete, your schema and data have been migrated to the Azure SQL Database instance. You can then shut down and decommission your on-premises databases and servers.
VM - Post-migration steps:
After the migration has taken place, review the security settings of the virtual machine after the migration. Restrict network access for unused services by using network security groups. Deploy Azure Disk Encryption to secure the disks from data theft and unauthorized access.
Consider improving the resilience of the migrated machines by:
Adding a backup schedule that uses Azure Backup.
Replicating the machines to a secondary region using Azure Site Recovery.
Complete clean-up tasks for the remaining on-premises servers. Such tasks may include removing the servers from local backups and removing their raw disk files from storage-area network (SAN) storage to free up space. Update documentation related to the migrated servers to reflect their new IP addresses and locations in Azure.
I provisioned an Azure VM with SQL Server pre-installed on Azure, but the decision has been made to re-install SQL Server with a different license. According to Azure documentation that means that I need to "deploy a new virtual machine and migrate the data and applications to the new virtual machine". Can I back up the OS VHD and migrate that to a new Azure VM without losing the applications and other prep work that's already been done and as a result drop the extra costs associated with using a SQL Server VM? How would I go about doing that?
As far as I know, unfortunately not.
You need to backup your data, move it off the VM (say to blob storage using AzCopy), build a new VM choosing the right license/sku from the store, then restore your backup and redeploy your apps.
See a similar question here
Is it possible to create a Azure VM (medium or large) running an instance of SQL Server. This machine would contain various databases (one of each client). These databases would then need to be accessible from different Azure VM's which would be hosting either a single website per vm or multiple website per vm each requiring to access different databases.
If it is possible:
How do the other Azure VMs connect to the relevant VM that's running SQL server and connect to a specific database?
What cost implication are there? We store a lot of data including documents as blobs.
Our software supports both storing the documents as blobs or as actual files. Should we consider storing the files directly onto the hard drive instead of storing them in the database? Would this improve performances when running on Azure VM and/or reduce cost?
What's the recommended solution for backup? I assume that Azure VM can go down, though less likely, just like any other machines. What the recommended solution to restore a back?
Same for SQL Server. What is the recommended solution to backup database. Since we'd be running a full version of SQL on a Azure VM, is the best solution to have a separate storage drive and backup databases on this?
Thanks.
1-)You can create a Virtual Network and after that, create your VM's and set them to use this virtual network. Doing that, your vm's would call the vm with your sql server.
2-) You'll be billed for network, storage and vm compute (including vm size). The best you can do is create a vm and test for a little (with this settings). So you'll know how much your are spending.
3-) When you create a vm, the vhd is stored in a storage account. There's a backup for that, but you can download the vhd and make a version of that on premises.
4-) My suggestion, attach a extra disk to your VM and use it to SQL Server Backup.
I'm new to Azure, and a little confused about blob storage. I have a need for clients to access via FTP / SFTP to push and pull files (XML, CSV, EDI, etc). The pushed files are read in by a .net application and written to a database. As I understand, we would use a VM role to create a FTP / SFTP server, a worker role to execute the .net code, SQL Storage for the DB and Blob storage for the files.
Am I correct in this assumption first, and second can a VM role attach a storage blob for writing and reading files and can a worker role attach to the same storage blob to read and write files as well.
Sample:
client pushed xml file to VM via FTP. VM writes XML file to storage. Worker role reads file, processes it and writes contents to db.
Is my thinking correct or am I missing the boat?
Thanks
Given Azure has an array of services so you have a few options. One important thing to keep in mind with Azure is that your worker roles, which are simply Windows Server 2008 without IIS installed, are very flexible so there is a lot you can do with them – this includes writing your own FTP server and being able to host it via a worker role VMs. The FTP to Azure Blob Storage Bridge (on CodePlex) solution is an example of this.
In addition, you could use a web role (which is the same as a worker role but with IIS enabled) to do the same - so rather than rolling your own FTP server you can use IIS. A visual guide to setting IIS up to run as an FTP server in Azure can be found on ITQ.
I’d recommend doing some further reading to determine which is the better option of the two. Also have a think about you requirements as this may influence your approach, i.e. scaling, bandwidth, costs, your preferred deployment model etc.
As far as storing the files goes you can certainly use Blob Storage. If you have no need for a relational database in your system then you could skip using SQL Azure altogether (in which case the web role solution referenced above won’t be of much use) – but again that comes down to your particular requirements.
The official Windows Azure website is a good source of knowledge, especially if you’re getting started, so do take the time to look through some of the pertinent documentation.
I've just setup an extra small VM instance in Windows Azure to run a help console for our company. The help files can be updated and published through a simple .NET interface. Obviously the flat html files are getting deployed to the local drive on the VM and exposed publicly through IIS. I'm just wondering how stable this is? If the VM suffers a hardware failure, presumably there's no automatic failover and any edits we've made to the help system will be lost?
Can anyone recommend a way I can shuttle the source files out of the VM into blob storage? I could write a an application to do this, I'm just wondering if there is an out-of-the-box solution out there?
Additional information:
The VM instance is running Server 2008 R2 SP1 (As a Virtual Machine not a web-role)
A backup needs to be created once every 24 hours
Aged backups (3+ days old) need to be automatically cleared from the blob container
The help system we use is called HelpConsole 2012
New pages are added at a rate of myabe 2-3 per week
The answer depends on how whether you are running this in a Windows Azure Virtual Machine or on a Windows Azure Web role.
If you are running this on a Windows Azure Virtual Machine, then the VHD is stored in BLOB storage and, if the site is running of the C: drive and not on a data Disk, then the system has some Host caching turned on for both reads and writes. In this scenario it is possible (depending on the methods you use to write your files out) that the data is not pushed back to the VHD in BLOB storage before a failure occurs. You can either ensure that your writing methods do a write through operation, or turn off the write caching. Better yet, attach a data disk for your web site files. By default data disks have both read and write caching off (you could turn on read caching). Since the VHD's are persisted you don't have to worry about the concern of the edits getting lost. You can script out taking a snapshot of the files and move them to BLOB storage separately, or even push them somewhere else. Another thing to think about with this option is that you have to care for the VM instances and keep them patched and up to date.
If you are running a Web Role, then yes, if a failure occurs and the VM goes through self healing it will indeed redeploy with the older files. In this case I'd recommend changing the code in the web role that when it writes the updates to the local file it also puts a copy of the local file into BLOB Storage. In addition, in the web role OnStart you could reach out to BLOB storage and pull down all the new content locally. BE VERY CAREFUL with this approach though because it only really works well for ONE instance, not multiple. If you plan on running multiple instances of the server (and you will have to if you want the SLA for uptime) then your code will need to be a little more robust and do writes out to BLOB storage and then alert all instances of the role that there is a new file to pull down locally.
Another option for web roles is to also write a handler for the content so that requests come in and are mapped to a file BLOB Storage directly. Then updates can occur to direct edits to the file in BLOB storage. This offloads the serving of the flat files from your compute nodes to BLOB storage and you could even implement some caching and stream the content back through the handler rather than having them hit BLOB storage directly if you wanted to.
Now, another option, is to use Windows Azure Web Sites for this. The underlying storage of the web site files in Windows Azure Web Sites is a shared location and thus updating the files in it will immediately be reflected for all instances. Also, the content for the site is stored in BLOB storage and can be updated via FTP, source control, or directly from code. Lots of options here. You may end up moving to reserved instances to help keep away from some of the quotas that Web Sites have. Web Sites may not be an option for you currently depending on other requirements (as in how much control do you need over the environment since you don't get a lot of control for Web Sites).