I'm setting up my environment in azure and I´d to know how I can put my VM on the same network as my application server (web sites)?
Currently, there is a big latency between my database (on VM) and my application (on web sites).
You can add them to the same Virtual Network, to add a VM to a virtual network in the old portal remember to choose to "Create from gallery" as that is the only place where you can choose virtual network.
In the new portal you can add a website to the Virtual Network when opening the website.
One point worth remembering is that it is a VIRTUAL network, but as it used to be with affinity groups a VNET should make sure that your servers are located "close by"
You can connect Azure Web Applications to VNETs - the best practice is to make sure they are in the same data center.
You're still going to have some latency (more than what you would on your local dev machine) - but as long as they are in the same datacenter region (EAST US, etc), that should minimize latency.
Your database should also not be open to the public (best practices here), and a VNET would solve this problem.
Related
On Azure, I have a two-VM set (both classic), whereby my web application resides on one VM, my database on another. Both map to the same DNS and belong to the same Resource Group, but both are acting as standalone cloud services at the moment. Let me explain: currently the web application communicates with the database over the public DNS. However, I need them to be on the same lan, so I can de-risk security and improve latency.
I know for a fact that they're not part of a virtual network because when I try to affix a static private IP to my database VM, I'm shown the following prompt in the portal:
This virtual machine can't be configured with a static private IP
address because it's not deployed in a virtual network.
How should I proceed to fix this misconfiguration and what should my next concrete step be? The website is live, and I don't want to risk service interruption. Ideally, both VMs should be in the same virtual network, and should communicate with eachother via a static internal IP. Please forgive my ignorance. Any help would be greatly appreciated.
I guess i'll be the bearer of bad news. You have to delete both VMs while keeping the VHDs in the storage account, then recreate the VMs (reattaching the disks) in the Virtual Network.
Since these are Classic VMs you can use the old Portal when re-creating them. You'll find the VHDs under "My Disks" in the VM creation workflow.
Alternatively, just restrict the inbound access with an ACL on the database Endpoint. Allow the VIP of the first VM and deny everything else. This is good enough for almost any scenario, since if your Web Server gets compromised it's game over. It makes no difference how they exfiltrate stuff off your database (over a VNET or over VIP).
Here's the relevant documentation page for setting up Endpoint ACLs:
https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-windows-classic-setup-endpoints/
I have several virtual machines in the azure network. Instead of creating users separately for each machine I would like to create the users at the network level. It will be easier for me to maintain users at the network level.
I am guessing it is not possible to add users to the virtual network because so far I haven't found anything while googling for the question and there is nothing in the Azure Management Portal Virtual Network settings that hints that this feature is available. If this is correct then would you like to suggest a workaround?
You cannot add users to a virtual network in Azure. You can only add VMs (IaaS) and Web and Worker Roles (PaaS) to virtual networks.
In the case you mean to authorize users to access Windows VMs, then think about an Active Directory Domain for your VMs and join all your VMs in that domain.
Here is a guide how to do this: Install a new Active Directory forest on an Azure virtual network
We are planning to rent have two VMs (one for Web Server and another for Database server) on Azure. I would like to know what would be the best way to communicate Database server from web server.
Direct communication using DNS.
Keep both the VMs in Cloud service and use host name to communicate.
Form a virtual network and use the persistent virtual machine IP address to connect to.
Thanks In Advance
you don't want to use the Clud Service host name to communicate between the VMs.
If you want to use DNS, you have to provide DNS - you don't need that too.
For that particular scenario, I would recommend something even simpler:
Put the VMs in the same Cloud service
Do not go for any Virtual Network or DNS Solutions
Use VM Name to connect between the machines.
when the VMs are deployed in the same Cloud Service and not in Virtual Network, Windows Azure provides automatic name discovery. The simplest approach is usually the best.
For more information on name resolution scenarios in Windows Azure, read this paper.
I have an Azure Cloud Service (Worker Role) that needs to connect to my Azure SQL database and also connect to an external database.
In development the external database was on the public Internet and connectivity was not a problem.
However, the solution now needs to be deployed in a production environment and access to the external database is to be restricted by setting up a Virtual Network.
The Cloud Service, when deployed in the Virtual Network, gets an IP from the subnet, but seems to become inaccessible to the outside world, and is not connecting to the Azure SQL database (I also cannot RDP to it).
This seems to be beyond my level of understanding of networking, but I don't see why it should lose access to its neighbours in the Azure environment.
What am I missing? Do I need to get involved with Endpoints? Is the Virtual Network misconfigured?
Thanks in advance.
Your question is quite vague, in terms that it does describe the whole picture in the best possible way. Let me put my answer based on my understanding about your issue.
First of all - Azure virtual Network is Virtual Network. It is designed to enable secure cross-premisses connectivity with Windows Azure Data Center.
When you deploy a proper PaaS Cloud Service (Worker Role / Web Role) in a Virtual Network, the role instances get IP Addresses allocated from the defined DHCP pool (the VNet Definition).
When you deploy any service in an Azure Virtual Network you have to take care of Name Resolution! Meaning that, if you do not provide a proper DNS Server, your cloud instances will not be able to resolve any address. That includes Azure SQL Database servers. More on Name Resolution can be read here.
Next, but not less important - Azure SQL Database servers are not part of, and, as of March'2013, cannot be added to Azure Virtual Network!
The last statement means that in order for your Worker Role to access Azre SQL Database server, you need to provide a proper DNS server in your Azure Virtual Network.
And lastly, when you deploy a PaaS service into a Virtual Network, in order to access it via Remote Desktop need to:
* Properly enable and configure RDP extension. it will anyway create Input Endpoint. But this is the only way to enable RDP on PaaS right now;
* You could probably enable RDP via PowerShell startup script and access RDP via the VPN tunnel for the Virtual Network - say you configured a Site-to-Site or Point-to-site VPN for your Azure VNet.
Check the building cross-premises Virtual Network guide here.
How to create 2 connected virtual machines in Windows Azure to be able to deploy Two-Tier-Architecture solution ?
Let me clarify the scenario, Currently I am using 1 virtual machines in Windows Azure where I have the SQL Server 2008 DB installed AND the ASP.NET solution.
However, I want to create a very simple Two-Tier-Architecture where the SQL Server 2008 DB is installed on Server1, and the ASP.NET solution is deployed on Server2.
So, How to accomplish that? I mean, How to connected those two separate virtual machines? And how they can work together to run one single solution?
Could you please help me out in this scenario ?
Thanks !
Seems like a lot of attention being given to Virtual Networks. That's fine, but... if all you're trying to do is create a multi-tier app with a handful of VMs working in conjunction with each other, you can simply create multiple VMs within the same cloud service (that is, they all live in xyz.cloudapp.net).
They'll all sit behind a single public IP address, but consider your case where you have a web server and a database server:
Expose ports 80 and 443 specifically for the web server(s) (you can have multiple, and load-balance the ports across these VMs
Don't expose any public ports for the database server
Once deployed to the same cloud service, each VM in the cloud service can talk directly to any other VM in the cloud service, using the host name you assigned to it.
You can also deploy your web and database tiers to different cloud services, and still communicate between them without a Virtual Network. If you open, say, port 1433 on your database server, now your web tier can simply open a connection to yourdb.cloudapp.net:1433. Of course, this means the entire world can do the same, but... you can apply an endpoint ACL (access control list) on yourdb.cloudapp.net port 1433, and allow only the public VIP of your web tier's cloud service.
You'd need a Virtual Network if your web and database tiers are in separate cloud services and you don't want any exposed ports on your data tier, and you don't want to go through the built-in load balancer.
You should utilise Virtual Networking (http://www.windowsazure.com/en-us/services/virtual-network/). Additionally you can configure the two machines as part of a single Cloud Service to ensure they are encapsulated together and available publicly via a single cloudapp.net address. Note that to benefit from the Azure SLA you should run two instances of each tier (web / DB).
Note that you can't add an existing VM to a new Virtual Network.
You can create a virtual network and then add both servers in the same network if they are on different cloud services (which is the default when using quick create). But you can't do this to servers that have been created so you will need to detach your disks create 2 new servers in the new network and then reattach your disks to the new servers.
If you are planning on using a DC then create 2 subnets in your virtual network and put your DC in one and the servers in the other as you don't want your DC getting a different IP.