We have existing Web application which has following layers
Web Layer (Asp.Net MVC ) Sql Server 2012 SAP ETL services: ETL
jobs pulling the data from different datasource to sql server
We have QA,STAGE,Production environment for the application.
We are planning to migrate the application to AZURE PAAS.For Web layer there is no issue's in migrating to PAAS.
For DB Layer we have used microsoft migration steps using visual studio there is no issues at data base design level.
the only concern moving DB to PAAS is SAP ETL service and application jobs which is dumping millions of data to database. Not sure about how many DTU's it will consume.
Just need help to decide for the above scenario is it good to move DB to PAAS or have Sql server VM ?
Thanks
I think it will be best for you to make some tests and base your decision on the results. For example, create an Azure Sql Server (Standard S0) and see how that performs. A great benefit of the PaaS offering, as you probably know, is that many aspects are handled for you automatically - upgrades, you can easily switch to another performance level, DB backups and restored, etc.
There is a very good article which can give you some additional pointers on how you can evaluate the pros/cons in your situation - Choose a cloud SQL Server option: Azure SQL (PaaS) Database or SQL Server on Azure VMs (IaaS)
I would personally choose the PaaS option. I have used Azure Sql Server for a long time and I never want to go back to configuring and supporting my own SQL server.
Related
I'm about to deploy an ASP.NET web application for testing in production. Essentially, this is just a table that is linked to a SQL Server table/view that is obviously dynamic when the data in the tables are updated.
I have a hosting plan with a site that I'll be pushing the files to, which includes a SQL Server database in the hosting plan. I also host a SQL Server instance on the network.
My question is, what is the standard way of dealing with SQL Server in this deployment? I think I have the options below, but as someone who has only ever developed applications offline, this is new to me, so please excuse my novice ignorance.
Have the application connect via IP address in the connection string to my SQL Server instance, as specifying the server name (SQLDEVSRV01 for example) won't be on the "network" when it's sitting in the site's FTP. Am I to assume my connection string will only work on the network, and once deployed to a website, will cease to function unless connecting via TCP/IP?
Host the server on the web in the same site host location. So upload the site files to my website host and setup the SQL server there. Would I be able to just specify the Server name (SQLDEVSRV01 for example) in the connection string there, as whilst it wouldn't work in development as it wouldn't be on the same network, it would then work once deployed on the web?
Embed a SQL Server instance within the app using localdB or something similar to hold the background data. If this is the case, can the data be accessed from the backend, either using SSMS or some other method?
Essentially, my aim here is to have the web app retrieve the data live from a view/table hosted in SQL server, where the backend data can be amended, manipulated and updated independently of the app, so the app can just pull the data when refreshed.
The standard way of doing this is to deploy your database to the hosting providers SQL Server instance and then connect your app to it using a connection string with their details. As it is normally a shared instance you do not have to normally worry about having the SQL instance machine patched etc.
Personally I would not be installing SQL Server myself unless I decided there was benefit to having an instance I wanted the control over nor would I be changing the structure or implementation of my application to suit a hosting providers setup.
I recently installed BizTalk Server Dev 2010.
As part of installation, new databases are created and some services are also added.
Because I am currently NOT working with BizTalk Server, I want to stop the service associated with it specially the one that connects to SQL Server.
I have already stopped these three BizTalk services:
BizTalk Service BizTalk Group
Enterprise Single Sign-On Service
Rule Engine Update Service
but not able to find the one that communicates with BizTalk SQL Server Databases.
I can still see BizTalk SQLs in profiler.
Any idea which other service I should stop?
Thank you!
There are also SQL Server Agent Jobs created to backup the database and keep the message box and tracking databases running. That is probably what you are seeing activity from.
I have seen variations of this question but couldn't find any that dealt with our particular scenario.
We have an existing aps.net website that links to a SQL Server database.
The database has clr user-defined types, hence it can only be hosted in Azure VM since Cloud Services don't support said types.
We initially wanted to use a vm for the database and cloud service for the front-end, but then some issues arose:
We use StateServer for storing State, but Azure doesn't support that. We would need to configure either Table storage, SQL Databases, or a Worker role dedicated to State management (a new worker role is an added cost). Table storage wouldn't be ideal due to performance. The other 2 options are preferable but they introduce cost or app-reconfiguration disadvantages.
We use SimpleMembership for user management. We would need to migrate the membership tables from our vm instance sql server to Azure's SQL Databases. This is an inconvenience as we want to keep all our tables in the same database, and splitting up the 2 may require making some code changes.
We are looking for a quick solution to have this app live as soon as possible, and at manageable cost. We are desperately trying to avoid re-factoring our code just to accommodate hosting part of the app in Azure Cloud services.
Questions:
Should we just go the VM route for hosting everything?
Is there any cost benefit in leveraging a VM instance (for sql server) and a Cloud Service instance (for the front-end)?
It seems to me every added "background process" to a Cloud Service will require a new worker role. For example, if we wanted to enable smtp for email services, this would require a new role, and hence more cost. Is this correct?
To run SQL Server with CLR etc, you'll need to run SQL Server in a Virtual Machine.
For the web tier, there are advantages to Cloud Services (web roles), as they are stateless - very easy to scale out/in without worrying about OS setup. And app setup is done through startup scripts upon bootup. If you can host your session content appropriately, the stateless model will be simpler to scale and maintain. However: If you have any type of complex installations to perform that take a while (or manual intervention), then a Virtual Machine may indeed be the better route, since you can build the VM out, and then create a master image from that VM. You'll still have OS and app maintenance issues to contend with, just as you would in an on-premises environment.
Let me correct you on your 3rd bullet regarding background processes. A cloud service's web role (or worker role) instances are merely Windows Server VM's with some scaffolding code for startup and process monitoring. You don't need a separate role for each. Feel free to run your entire app on a single web role and scale out; you'll just be scaling at a very coarse-grain level.
Some things to consider...
If you want to be cheap, you can have your web/worker role share the same code on a single machine by adding the RoleEntryPoint. Here is a post that actually shows how to do what you are trying to do with sending email:
http://blog.maartenballiauw.be/post/2012/11/12/Sending-e-mail-from-Windows-Azure.aspx
Session management is painfully slow in SQL Azure DB, I would use the Azure Cache if you can..it is fast.
SQL Server with VMs is going to cause problems for you, because you will also need to create a virtual network between that and any cloud services. This is really stupid, but if you deploy a cloud service AND a VM they communicate over the PUBLIC LOAD BALANCER causing a potential security concern and network latency. So, first you need to virtual network them (that is an extra cost)..then you also need to host a DNS server to address the SQL Server VM. Yes this is really stupid, unless you are OK with your web/worker roles communicating with your SQL Server over the internet :)
EDIT: changed "public internet" to "public load balancer" (and noted latency)
EDIT: The above information is 100% correct contrary to the comment by David below. Please read the guidance from Microsoft here:
http://msdn.microsoft.com/library/windowsazure/dn133152.aspx#scenario
DIRECTLY FROM MICROSOFT GUIDANCE speaking about cross Cloud Service communication (VM->web/worker roles):
"We recommend that you implement the first option as the connection process would not need to go through the public Internet. Therefore, it would provide a better network performance."
As of today (8/29/2013) Azure VMs and Worker/Web Roles are deployed into DIFFERENT "Cloud Services". Therefore communication between them needs to be secured via a Virtual Network that exposes private IP addresses between the instances.
To follow up on David's point below, that about adding an ACL. You are still sending packets over the internet using TDS (SQL Server protocol). That can be encrypted, but no sane architect/enterprise governance/security governance would "allow" this scenario to happen in a production environment.
I have an ASP application sitting on 2 servers, using a db in SQL Server 2012. The SQL Server uses AlwaysOn Availability groups but when these failover the client connecting to the ASP.NET application terminates. I have looked into the SQL driver which as it turns out the app is using SqlClasses so not using ODBC driver (from what I have deduced I presume that logic is sound but correct me if I'm wrong).
Another suggestion has been made that I load balance the 2 app servers and that will seamlessly allow failover underneath without the client loosing connection, is this a viable way to go? We don't have much control over the applications code to ask it to try the connection again after failing....
Many thanks in advance.
Try defining the failover partner in your connection string.
Data Source=myServerAddress;Failover Partner=myMirrorServerAddress;
Initial Catalog=myDataBase;Integrated Security=True;
And also check out MultiSubNetFailover property in .NET 4.5
I have a central webservice over the internet which gets different information from different softwares and stores them in a Sql server 2008R2 database.
In addition to webservice some windows applications exist in different cities which all of them have local databses.
Now I wanna have replication between these local databases and the central database. but there is no any direct connection as like as "VPN" between local databases and central database.
so how can I do something like replication or synchronization between local databases and central database over the internet.
I'm thinking about sending local databases via web service. what is your idea?
My local databases are Sql server 2000 version
How about log shipping? You can even use FTP (FTPS--FTP over SSL, for security) to send the logs to be later on applied to the central DB. Since you have SQL 2000, you'd have to restore data to a copy of the DB in "restore" mode and then merge with central DB using SQL.
Also, from personal experience--if setting VPN is costly, you can consider using SSH. Free implementations for Windows exist, and they do a good job for secure file copy, just like FTPS.
I wouldn't use a webservice for this purpose, especially if the amount of data is large.