With the lack of native SSAS support on Azure I am inclined to install it on a VM Role. I want to know if this sounds like a feasible option. Questions that come to mind:
It sounds like the VM drive is persisted on Azure Storage. Is this efficient for holding a SQL Server installation? Or are the drives not durable at all?
Can this VM be able to communicate with SQL Azure, Worker Roles, and Web Roles?
Can SSAS be accessed by Worker Roles and Web Roles?
If the answer to 2 or 3 is yes. Would the traffic be considered internal traffic or would it be subject to data transfer rates?
Thanks,
Yes - with the latest Virtual Machine announcements the drives are durable. So you can install SSAS on a VM along with SQL Server. Check out the details of the preview program here: https://www.windowsazure.com/en-us/home/features/virtual-machines/
A VM can communicate to SQL Azure like an other application as long as you open up the firewall to allow internal connections. I am not sure what you mean by accessing Worker Roles from a VM; what do you have in mind? Generally speaking you can access other endpoints through URLs; beware however that IP Addresses can change, so it's a good idea to have formal URLs for machines/end points you are trying to connect to.
The reverse is true as well; worker roles can communicate with other endpoints; just don't use IP addresses because they could change on you.
If you are deploying all your services within the same data center in Azure, it would all be internal traffic, so you would not be charged for that traffic.
The answers are as below:
Yes. You sure can use SQL Server 2008/2012 on any Azure VM. Be sure to have larger VM for better performance.
Yes, you can connect directly to Azure VM in between role as long as you have opened proper ports. As long as all machines are in Same DC this will not have any problem or need any special configuration.
Yes. #2 applies.
As long your egress/ingress is between all those machines are within same DC, it is all considered internal traffic.
Related
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.
I wasn't able to see any info on this.
Why I would want this? There are several developers using it's 'own' azure account to have their own servers but all connect to another server (database) on another account. So I think for this scenario it would be good to have all those servers on the same affinity group but there is no 1 azure account but many.
In case that's possible, how can I restrict that database server to allow access only from all those boxes and itself ?
The restriction can be made using IP addresses in the Azure firewall. But there is no way to put these servers into the same affinity group. They need to be part of the same overarching account.
I've a single Web Role Cloud Service instance running the South East Asia, with a SQL Azure Database running in the same region. I am hitting a firewall issue and the connection is blocked unless I add the Cloud Services public virtual IP to the SQL server firewall.
From everything I've read, if the two systems are in the same region, and 'Allowed Windows Azure Services' is enabled (which adds 0.0.0.0 to the firewall), then the two should be able to communicate internally?
I have some concerns about things being routed inappropriately (is data going outside the network / am I being charged for it), and having to reconfigure the firewall should the VIP change.
Is there some other address I am supposed to access the SQL azure instance by (currently hitting blah.database.windows.net)?
Your understanding is correct. If I were you I would open a support ticket with Microsoft; I have heard of this issue before, although I never experienced it myself. This sounds like an issue, so report it and watch your next invoice carefully.
Firstly,
Allowed Windows Azure Services - Will allow only azure services to access the database.
Secondly,
To be able to access the database server from any other endpoint, you need to add firewall rules to allow those specific IP ranges. If you want to connect from a machine with ip, 132.99.xx.xx you need to add a rule with start IP and end IP as 132.99.xx.xx
Hope this helps!