We are trying to migrate a VM in a private cloud to azure. This VM has multiple web applications and databases. We don't have access to the virtualization, just access to this single VM.
Can anyone suggest how we can do the migration to azure with just having access to the VM itself?
Regards
Anup
As far as I know and as per the document, we can't migrate Single VM without having access to Virtualization.
Because while processing Migration you need to generate Project Key where you need to have access Virtualization.
You can go through the Microsoft Document for further details.
Related
My Application Architecture
I already have a working SQL Server integrating , Analyzing and reporting applications deployed on my on-premise server. Now I am planning to deploy the same reporting application into Azure cloud. I am planning to move this application to cloud.
My Exploration
When I am exploring I found the data factory for data integration and transform services and later can publish to any BI tools. I was reading the data factory documentations from the following link,
https://learn.microsoft.com/en-us/azure/data-factory/introduction
From here I understood that I can use Azure data factory and I can perform data integration and transforming using Connect And collect stage , Transform Enrich and publish stages. And Also we can use BI tools after publishing this.
Related with moving from on-premise to Azure Cloud, I had felt some confusions. I am adding below
My Confusion
Without using Azure's Data factory service , Is possible deploy my all service packages (SSIS/SSRS/SSAS) in my own Azure VM infrastructure like what I did in on-premise machine ?
Without using Azure's Data factory service, Is possible deploy my all
service packages (SSIS/SSRS/SSAS) in my own Azure VM infrastructure
like what I did in on-premise machine ?
Yes, you can install all the service packages in your Azure VM when you create the VM. See this description:
Azure virtual machines allow you to deploy a wide range of computing
solutions in an agile way. You can deploy virtually any workload and
any language on nearly any operating system - Windows, Linux, or a
custom created one from any one of the growing list of partners.
You can just treat the virtual machine in Azure as your machine on-premise. The difference is you cannot care about the hardware and Azure will maintain it for you. You can also control the permission of your VM with the Azure Service Principal. See more details about the Azure VM.
In Azure there are 2 options available to create virtual machines.
A. normal VM
B. Classic VM
Does anybody know what is the difference between both option? When do we use one over other?
Short answer to your question is Normal VM or Virtual Machines is the new way of deploying your Virtual Machines whereas Classic VM or Virtual Machines (Classic) is the old way of deploying them. Azure is pushing towards the new way of deploying resources so the recommendation would be to use it instead of old way. However please keep in mind that there're some features which are available in the old way that have not been ported on to the new way so you just have to compare the features offered and only if something that you need is not available in new way, you use the old way.
Now comes the long answer :)
Essentially there's a REST API using which you interact with Azure Infrastructure.
When Azure started out, this API was called Service Management API (SMAPI) which served its purpose quite well at that time (and to some extent today). However as Azure grew, so does the requirements of users and that's where SMAPI was found limiting. A good example is access control. In SMAPI, there was access control but it was more like all-or-none kind of access control. It lacked the granularity asked by users.
Instead of patching SMAPI to meet user's requirement, Azure team decided to rewrite the entire API which was much simpler, more robust and feature rich. This API is called Azure Resource Manager API (ARM). ARM has many features that are not there in SMAPI (my personal favorite is Role-based access control - RBAC).
If you have noticed that there are two Azure portals today - https://manage.windowsazure.com (old) and https://portal.azure.com (new). Old portal supports SMAPI whereas new portal supports ARM. In order to surface resources created via old portal into new portal (so that you can have a unified experience), Azure team ended up creating a resource provider for old stuff and their names will always end with (Classic) so you will see Virtual Machines (Classic), Storage Accounts (Classic) etc. So the resources you create in old portal can be seen in the new portal (provided the new portal supports them) but any resources you create in the new portal using ARM are not shown in the old portal.
The Azure Virtual Machine (classic) is based on the old Azure Service Management Model (ASM). Which revolved around the concept of a cloud service. Everything was contained inside a cloud service, and that was the gateway to the internet. While it is still used (extensively) Azure is now moving over to the Azure Resource Management Model (ARM).
ARM uses the concept of declarative templates to configure an entire solution (rather than individual components) So you can create an entire Sharepoint stack, rather than just a singular machine.
ARM also has a much more logical approach to networking. Instead of having a monolithic VM in an obscure cloud service. You have a VM, that you attach a network card to. You can then put the Network card into a VNet and attach a public IP (if you need one)
Unless you have a compelling reason to use ASM (classic) You should create your solution using ARM. As this is the MS recommendation going forward (todo find a link to that) It also means that you can create templates for your deployments, so you can have a repeatable solution.
On the negative, the old portal manage.windowsazure.com can not manage anything that is deployed using ARM, and there are still parts of ASM that haven't been migrated over to ARM yet. For instance you cannot configure Azure VM backup, since Azure backup is ASM and it can't 'see' ARM VMs
It very largely depends on your circumstances though, what it is you are planning for, the method you are going to deploy with. If you are just looking to stand a machine up to do a single task, it makes very little difference. If you are looking to deploy into an environment that will have some concepts of DevOps going forward, then ARM is the way to go.
The one big differences is for resource management. For that new version is called Azure Resource Manager VM (ARM VM).
ARM VM is better in terms of;
Classic VM must be tied with Cloud Service, and Cloud Service consumes resource limitation and not-so-flexible network configuration.
ARM VM is managed under Azure Resource Manager (ARM) which can be organized with/without other Azure services. ARM is like a folder of Azure services, and it gives you more fine-grained resource management.
Classic VM can be migrated to ARM VM version, but you have to afford service downtime. To migrate from classic VM, read the official article: Considerations for Virtual Machines.
Azure provides two deploy models now: Azure Resource Manager(Normal) and Azure Service Management(Classic) and some important considerations you should care when working Virtual Machines.
Virtual machines deployed with the classic deployment model cannot be included in a virtual network deployed with Resource Manager.
Virtual machines deployed with the Resource Manager deployment model must be included in a virtual network.
Virtual machines deployed with the classic deployment model don't have to be included in a virtual network.
I've been working through this tutorial to get started with cloud services in Azure.
The project has one web role and two worker roles, and they share similar code for accessing the storage tables. Could I have a common data access layer shared between them? Would I create a separate role for this? I'm not really sure where to start.
Yes you can, but is that what you want? Sharing the same access layer, all services will access the same database.
You just need to add a Nuget Package Windows Azure Storage and access your storage account / blobs, tables, queues...
I have been reading about LocalDB and how it can not be used in Azure Roles (since they do not persist if the role stops working) and that you should move towards either Azure SQL or Azure Storage.
However, is it possible to use the LocalDB in a Windows Azure VM? Because I do not currently have access to a Azure Account I am not able to test this myself.
Kind regards
Tom
Azure VM should work fine, since it is fully persisted and largely compatible with regular Windows. Note that I'm referring to the new Azure VM feature, not the old Azure VM Role, since the VM Role was not fully persisted. Just clarifying the answer in case someone doesn't read the question too carefully.
Microsoft Azure cloud supports three roles Web, Worker and VM with different capabilities to be utilized by application developers.
If I understand correctly when we use Web or Worker role, Azure acts more like PaaS while using VM role puts Azure in IaaS role.
Web, Worker roles has the advantage of OS/Platform being managed by the Fabric Controller (updates to OS etc), where with VM we have to manage those ourselves.
My question is, if we implement a private cloud using solutions provided by Microsoft, Can we still create Web/Worker roles on our private cloud, or is it limited to VM roles?
Cloud Services, which you're describing, are comprised of Web / Worker / VM roles, with Web and Worker OS's maintained by Microsoft and VM Role maintained by you (with multiple instances all based off the baseline image you upload). In all three cases, any type of new image creation is like starting fresh: changes made to the OS while running are not permanently persisted. VM Role does not put Windows Azure into IaaS mode, as the fabric is still using a single baseline image to manage role instances. IaaS, with Virtual Machines, is a bit different, with the Virtual Machines constructable in the cloud (vs. VM Role that requires them to be built locally and then uploaded). Further, any change to a Virtual Machine is persistent. When scaling to multiple instances, you'd need to make VHD copies from your master image, and then each instance would be living on its own (e.g. a change to one Virtual Machine will not show up in the other Virtual Machines).
Having said all that: You have access to Cloud Services (web/worker/vm role) only in Windows Azure today; there's no way to run these locally.
Recently we announced the availability of Windows Azure services for Windows Server. You'll see that there is a subset of Windows Azure features runnable on Windows Server:
Web Sites
Virtual Machines
Service Management Portal and API
The answer is not yet. WebRole and WorkerRole PAAS are relying on Azure Fabric Controller and that thing does not yet run on premise outside of Microsoft's control, as far as I know.
Yea as far as I'm aware you can, I haven't tried it myself, you need to create a VNET and then create your Cloud Services within your VNET, Michael Washam has a good post detailing it: Connecting Web or Worker Roles to a Simple Virtual Network in Windows Azure