Can someone please explain me what I need to do in order to make my websites available all the time using Microsoft azure.
At the moment I have just one dedicated server with IIS (running 7 websites) and SQL Server - all on one machine. Beside this I use Redis-lab as cloud service for hosting Redis cache.
I'm more or less happy how this works, but in case that something happens with server, or I need to restart it of course my website goes down which is not good of course.
So in order to make mitigate some of risks what exactly I need to do?
Am I correct in flowing thinking?
Option 1 - I need one more machine in an availability set with load balancer. This solution is not great as one server will still have an instance of SQL Server running = if that server goes down, websites on the second server will not work as the database is down
Option 2 - I need 3 more servers. 2 for IIS in a load balanced environment and 2 for SQL Server - which is super expensive solution.
Option 3 - 2 more servers. Where existing server and the new one will be for IIS (load balanced) + 3rd server with database. The database server will be write only. Both IIS severs will have an instance of ms SQL running in readonly mode => content from database server will be replicated to their databases. In this scenario if SQL Server goes down websites will still work as they will pull data from their own read only databases
Are there any other options?
Thanks
Regarding other options have you considered the option of moving the databases to Azure SQL which would give you redundancy out of the box? Similarly if you can move the websites to Azure App Service you can get the same for the sites.
Yes, you definitely need the availability set for your deployment. Please, take a look at Azure availability checklist written by Microsoft.
I would propose you to migrate your web apps to the Azure Web Apps + set up the SQL Server deployment according to the availability best practices. Migrating them to the web apps as a service will eliminate some administrative tasks and the problem of placing all of the eggs in the same basket. You can place them to the one Web Apps Pricing Plan and change that plan when needed, for example, from more powerful resources to least powerful (or from the paid one to the free one for all of your sites).
If SQL Azure is not a solution for you, and (from my point of view) the data source is more critical than frontent/.../, it is highly recommended to deploy SQL Sever according to the tutorials provided above.
Related
We have an Access 2016 database with lots of tables, forms and reports from a client. The client would like other people to access the data in this database but doesn't want to spend the money to convert the forms and reports to a website. They would rather have Access 2016 as a frontend with it's forms and reports and store the data in a centralized location. The issue is the users who will access this data won't be on the same LAN or network.
The solution I came up with was to use SQL Azure as the database backend and keep the forms and reports in the Access 2016 database frontend. Can anyone think of an alternative? Does Microsoft have some kind of online hosting with Office 365? I have nothing at all against SQL Server and use it frequently but just don't want to go through the effort of upsizing the database when a simpler solution existed.
You can certainly place the back end on SQL Azure. However given that a typical internet connection is about 100 times slower, then MUCH effort is required to optimize the application. So you need significant experience on how to optimize an Access application to work with SQL server. This setup is thus doable, but will take significant amounts of work to achieve decent performance.
Another possible solution is to use a SharePoint or office 365 back end (which supports SharePoint tables). This setup only works well if table’s sizes are in general below 5000 records. You also have to ensure all table relations are standard auto number PK and child tables use a standard long number column to relate back to the parent table.
Likely the best solution is to setup a server and run remote desktop. This gives the best performance, and the end users don’t need to install access nor your front end part.
I explain in detail the “slowness” with using SQL server over the internet in this article of mine along with some suggestions and possible solutions.
http://www.kallal.ca//Wan/Wans.html
I have a SQL 2012 database that I want to sync/replicate up into Azure.
Because we intend to use this in production we cannot use the Azure Sync tool that is currently in preview.
This needs to be near real time, and only one directional. (Only ever pushing data to Azure like a cache)
What are some recommended tools for doing this?
In my opinion:
SSDT - Sql Server Data Tools
http://thomaslarock.com/2013/01/sql-server-data-tools-why-must-life-be-so-hard/
http://msdn.microsoft.com/en-us/library/dn266028(v=vs.103).aspx
http://msdn.microsoft.com/en-us/data/tools.aspx
if you're using Azure SQL Database, you can have a look at SSIS, Sync Framework, etc...
the biggest challenge you'll have is not the sync, but the near real time requirement that you have.
The best approach to this problem is to use the Sync Framework, create an agent that sits on a Worker Role in your Azure environment, and a client agent that is on your network.
Here is an end-to-end sample: http://code.msdn.microsoft.com/Windows-Azure-Sync-Service-60293622
Here is another option, this one uses a two-tier approach that is simpler and may be more suited to your push-only scenario: http://blogs.msdn.com/b/zkap/archive/2012/04/12/synchronize-sql-server-and-sql-azure-using-sync-framework.aspx
So I'm inexperienced in hosting DB's and I've always had the luxury of someone else getting the db setup.
I was going to help a friend out with getting a webpage setup, I've got experience in Asp.Net MVC so I'm going with that. They want to setup a search page to query a db and display the results. My question I have is in getting the DB setup and hosted. They currently just have the Access DB on a local computer. There is basically only one table that would need to be queried for the search.
What is the best approach to getting this table/db accessible? They would like to keep the main copy of the db on the local machine, so copying the entire db over to the hosted site would be time consuming, could the lone table needed be solely copied to the host? Should I try to convince them to make changes on the hosted db and just make copies of that for their local machines? Any suggestions are welcome, Again I'm a total noob when it comes to hosting databases.
Thanks
Added: They are using a MS Access 2000, and the page will have access restrictions. Thanks for the responses.
How about SQL Server Express? I think you can do a remote connect from Access and just push the data over from Access.
I wouldn't use Access on a web server in any case.
I would strongly recommend against access from web work, its just not designed for it and given that SQL server express is free there is no reason not to give it a go.
You can migrate the data over by using the SQL server upsizing wizard, here is a link for help on using that feature
http://support.microsoft.com/kb/237980
It depends on what you mean by web work? Access 2010 can build scalable browser neutral web applications. They can scale to 1000's to users. In fact, you can even park the web sites on Microsoft's new cloud hosting options, and scale out to as many users as you need.
Here is a video of an application I wrote in access 2010. Note how at the half way I run the same application including the Access forms in a standard web browser. This application was built 100% inside of the Access client. The end result needs no ActiveX or Silverlight to run.
http://www.youtube.com/watch?v=AU4mH0jPntI
So, the above shows that access can now be used to build scale web sites (you can ignore the confusing answers by the other two posters here they are not quite up to speed on how access works or functions).
However, for your case, I would continue to have the access database on the desktop. You can simply link to tables that are hosted on the web server. Those tables can exist in MySql, or sql server. As long as the web site supports external ODBC connections (many do), then you can thus have the desktop application use the live data from the web server. If connections to the live data at all times is a issue, then you could certainly setup something to send up new records (or the whole table) on some kind of interval or perhaps the reverse, and pull down new records on a interval from the web site (depends which way you need to go). So, connecting to MySql or sql server is quite easy as long as the web hosting and site permits external ODBC connections. I do this all the time, and it works quite well.
As mentioned, new for access 2010 is web site building ability but that does requite Access Web services running on SharePoint.
You don't need to upgrade to Access 2010. One option is to use the EQL Data plugin to sync the database up to the server. Then you can write an asp.net, php, or whatever application that queries the table using the EQL API and prints the results however you want. This kb article describes how to use the EQL API from a web app.
The nice thing is that the database is still totally usable (and at full speed) even when you're not online, and then you can sync the new data up to the web occasionally. It only uploads the changes, not the entire database every time, so it's fast.
Disclaimer: I work at EQL Data so I'm a bit biased. But this kind of use case is the whole reason the company exists.
There are actually two related questions:
is it possible or advisable to use a full blown stand-alone SQL server for SharePoint Services WSS3.0 instead of the supplied windows internal database it comes with? The client I am working for is asking to utilize their existent SQL server for all WSS content databases to possibly minimize admin effort and improve performance.
As well, would you advise to install WSS on one physical server and the content database on another server? Any gain in performace? Practicality? ect. The default is WSS and all of its databases are installed on the same single server. We don't really need a farm setup of MOSS, because the WSS capabilities are enough for our needs.
Thanks,
Val
Yes, when you create the site check the installation to be a "Web Front End" It will then prompt you to select a location for the SQL database. Just point it to which server you want.
I would definitely recommend putting it on a non-Sql Express instance. The express version only scales to 4 gig, limits the maximum number of connections etc. If your client is going to do much with it at all, you will eventually hit that limit. Full blown sql server has other advantages too, like help with backups etc.
Yes and yes.
Keeping the SQL and WSS servers separate saves resources on both, and neither are light weight applications. It also allows you to easily begin clustered/distributed environment in the event your usage increases, as well as following a least privledge principle, keeping product patches separate, etc.
As an addendum, you say you don't need a MOSS farm because WSS fits your needs, but be aware that it's just as easy to setup a distributed WSS environment as is MOSS; MOSS only adds capabilities to the application. It's usually a good idea to have at least two WFE's in the farm, if for nothing else than redundancy in case of failure.
Yes you can use a 'full blown' SQL Server instead of the the free and limited SQL Server Express that is delivered with Windows SharePoint Services 3.0 (wss 3.0)
It's even better to separate the database and the actual website! More scalable (if you upgrade to MOSS), easier to manage and less security risks.
Scenarion:
I am having a web application which is going to use SqlServerReport(SSRS) sitting on ReportingServer which is on my DatabaseServer.
There is a firewall between webapplication & SqlserverReport server.
Now how safe is it to use reports directly from webserver (ie accessing something there on database server.)
We use a appserver to interact with the database data.
All basic calls are
UI ==> AppServer ==> DatabaseServer (general cases) :) happy
UI ==> DatabaseServerReports (to access Sqlserver reports) :(
So my concern is how safe is to access reports directly from Databaseservers.
Yo need to open the ports 80(http)/443(https) in the firewall to using the SSRS server from the AppServer.
Please, contact your Network Admin.
Our security folks made us install IIS on a separate partition.
Why not use your app to display the reports? With ASP.NET you can use a report viewer control to display the report so the user has no idea where the report is coming from except that it is within the application.
How safe depends on where the user is located. SQL Server Reporting Services was not intended to be opened up to the Internet, for instance. Neither was the SQL Server database engine, for that matter. You said there's a firewall between the web server and the SQL Server, but that's not an unusual configuration in internal networks nowadays.
The concern that might come up is one from the performance side, more than any other. By viewing the reports using SSRS, the report rendering will occur on the same server as your database engine. If the hardware isn't enough for both roles, you'll see performance issues.