We have a website up and running, and we decided to move to Azure.
The database was migrated to SQL Azure using the DMA (Data Migration Assistant), and we created a VM on Azure, then we published the website on IIS on the VM.
Now, we have two different domains with two different databases, and the old website is much faster than the new one (azure website).
We couldn't find exactly where is the bottleneck; in the database, or in the connection, or in the VM (processor or IIS, ...).
The specifications of the Azure resources:
VM: Standard D2s v3 (2 vcpus, 8 GB memory)
DB: Premium P1: 125 DTUs
Can anyone hint us how to detect the main cause of this slowness?
If your application have load then the best practice to do that host your application on a different azure machine and host your database on a different azure server and make a virtual network between your machines.
When you create an Azure virtual machine (VM), you must create a
virtual network (VNet) or use an existing VNet. You also need to
decide how your VMs are intended to be accessed on the VNet. It is
important to plan before creating resources and make sure that you
understand the limits of networking resources.
Load balancers
Azure Load Balancer delivers high availability and
network performance to your applications. A load balancer can be
configured to balance incoming Internet traffic to VMs or balance
traffic between VMs in a VNet. A load balancer can also balance
traffic between on-premises computers and VMs in a cross-premises
network, or forward external traffic to a specific VM.
The load balancer maps incoming and outgoing traffic between the
public IP address and port on the load balancer and the private IP
address and port of the VM.
Read this to configure.
Related
from my customer I have the following requirement:
A VMware host shall manage VMs for application clients running on Windows Server 2016. In the plant of the customer there are 75 operators concurrently working with this application.
Therefore, my idea is to create a RDS Host VM which is providing many concurrent Windows sessions. The operators get thin clients and connect via RDP to the hosrt where the application is installed.
Unfortunately I have no experience how to correctly setup the architecture for RDS Host correctly.
From the application developer there is the recommendation to host at maximum 25 sessions per RDS Host. This would mean I need 3 RDS Hosts, that arrange somehow internally which operator is connected via which RDS Host.
How is this connection management performed within RDS? Is there a centralized instance managing it?
What are the virtual hardware requirements for such an RDS Host? Do I just multiply the single session application requirements by 25 ?
In case on host fails, is it possible to dynamically turn on an additional VM that takes over?
Is it correct that I need 75 Device CALs?
Thanks for you help!
I was thinking not to set any External IP Addresses on the cockroach database cluster that I will be launching, as I would be connecting to the cluster using the Internal IP Addresses itself.
I am deploying the cluster on GCP (Google Cloud Platform) and would have other application servers that would have External IPs and would interface with the Database Cluster.
I wanted to know, if there are any drawbacks or generally not a good practice to proceed with the above configuration.
In my opinion it is a good decision to avoid external IPs as much as possible, especially for databases and backend servers. it is an increase in security on the expense of convince in connecting (e.g. direct SSH).
You'll be able to SSH to such servers as needed by opening SSH tunnels from other VMs in the same VPC or VPN (openvpn, tinc, ..).
We've been experimenting with hosting our ASP.NET + SQL Server application in Azure. We've tried two ways so far:
App Service for ASP.NET, VM for SQL Server, both in the same data-centre, so I imagine a LAN connection is possible, but currently the connection string lists the public IP
A single VM for both IIS ASP.NET and SQL Server (an interim solution - we will eventually move SQL behind a firewall)
We'd prefer the first option because of costs and manageability. But it seems slower (I guess because of the public IP in the connection string).
Question
Can the App Service - SQL connection be LAN rather than WAN/internet? Are there any specific tricks during setup to achieve this?
What I've tried
The SQL VM is in a VNet. I've tried adding the App Service into the VNet (based on the guess that it'll then be able to see the SQL VM's internal IP), but the existing VNet is not selectable in the App Service's VNet configuration options.
Can the App Service - SQL connection be LAN rather than WAN/internet?
According to your description, maybe we can use VPN to integrate your app with an Azure Virtual Network.
When we want to select one Vnet for Azure app service, we should setup a point-to-site VPN with a Dynamic routing gateway.
Getting started
Here are some things to keep in mind before connecting your web app to
a virtual network:
•VNet Integration only works with apps in a
Standard, Premium, or Isolated pricing plan. If you enable the
feature, and then scale your App Service Plan to an unsupported
pricing plan your apps lose their connections to the VNets they are
using.
•If your target virtual network already exists, it must have
point-to-site VPN enabled with a Dynamic routing gateway before it can
be connected to an app. If your gateway is configured with Static
routing, you cannot enable point-to-site Virtual Private Network
(VPN).
•The VNet must be in the same subscription as your App Service
Plan(ASP).
•The apps that integrate with a VNet use the DNS that is
specified for that VNet.
•By default your integrating apps only route
traffic into your VNet based on the routes that are defined in your
VNet.
More information about integrate App with an Azure virtual network, please refer to this link.
Is it possible to have a WCF service that is running on Windows Azure communicate with a local / on-premises SQL Server database?
Alternative options we're considering are:
Push the 4 SQL Server databases that the WCF service needs to gather and process data from up to a Azure VM
Create 4 SQL Azure "clones" of the local / on-prem SQL Server databases and use the data sync feature to keep the Azure clones in sync with the local data.
Ideally, we'd like to be able to expose the on-premises database (via the VPN) to the service and hit each of the databases directly.
Yes, you can make outbound connections from any Azure hosted service, whether running in web sites, cloud services or virtual machines. If you need traffic going through a VPN, you'll need to use cloud services or virtual machines, since web sites can't be added to a virtual network.
Actually, an easier solution would be to host your WCF service internally and expose the service via an Azure Service Bus Relay. The service bus relay supports multiple authentication types for securing the service and no VPN is required. There is a good walk-thru here - .NET On-Premises/Cloud Hybrid Application Using Service Bus Relay. We have successfully used this technique to expose several services to third-party vendors.
you can set up Site-to-site VPN as shown in this resource - Step-By-Step: Create a Site-to-Site VPN between your network and Azure
I would think of SQL Data Sync for scheduler times and that too for small amounts of data (at least not in millions)
We are building a client solution that will be hosted on servers in a data-centre. It consists of several servers all related to providing the client solution. There is no internal network to protect but for some reason our UAT environment has the notion of a DMZ in the server diagram.
We have an IIS box which will have a public IP. Then we have two servers DB(Sql Server) and APP that are only on the internal lan with no public IPs. You can only RDP to these servers via VPN. Our IIS server needs sql access so port 1433 is open from IIS box(DMZ) to the sql server. We are also opening several ports from the IIS server to the APP server which hosts WCF services.
My understanding was that a DMZ was meant to protect internal private networks and that these networks should not be accessible from the DMZ but we are now opening up ports to both our APP and DB servers so they are accessible from the DMZ. In the end most of our servers are accessible from the IIS server via certain ports.
We originally wanted to setup our SQL server for AD authentication only but since our IIS server is in the DMZ and has no AD access we will be forced to enable mixed mode authentication in SQL server. This might be another security issue in it's own since we are now forced to store passwords somewhere on the IIS server to be able to auth against sql server.
Are we not perhaps missing the idea of a DMZ?
So with a system where you have a DMZ, there is also a firewall involved.
So your system should look like this I think:
SQL-server hosting internal data
Other servers needed for the company
---- firewall ----
SQL-server hosting data for web solution
AD-server (if needed)
Web-server
FTP-server (could be on the web server also)
With this setup you don't expose company-sensitive database to the outside world and you also don't open up a port in the firewall making it possible for attackers to (maybe) get access to the internal database which has company sensitive data...
Just my suggestion based on the information provided.