I know that we can have one WebRole for many sites using "Sites" section.
I'd like to know the limit of this : In which cases is it better to create a new WebRole ?
The documentation claims that you have "full IIS" - so the limits will be quite high - I've seen inside one shared hosting setup with well over a hundred sites running on the same IIS box.
At a practical level, the limits will depend on:
how busy your individual sites are - how many resources each one requires in terms of network bandwidth, CPU, RAM, and disk space.
how hard it's going to be to administer all your sites as one entity - it can be quite hard to synchronise the upgrade of multiple sites at a development team level, and it can generate additional testing (are you sure that upgrading site B hasn't changed sites A and C?)
whether you want all your sites to scale together horizontally or whether you want to scale them independently.
Related
Is it applicable to have both SharePoint 2013 and Sitecore 8.2 installed on the same servers (sharing the same Infrastructure)? If yes, is there any drawbacks?
Thanks for your appreciated help in advance.
Technically speaking it is safe, but both will make usage of IIS infrastructure to deliver their websites, and the machine hosting will take its toll on memory and possibly disk I/O depending on how any of these products were configured to store their data.
I had the unfortunate "pleasure" to work with Sitecore 7 and 8, and I can guarantee you it is possible and somewhat safe, but there are conditions to meet, let me go over some possible red flags here and it will hopefully help you to make a more balanced decision on how to set up both products on the same infrastructure.
The first scenario and the safest: 3 SERVERS
SQL Server with two instances, segregating SharePoint and Sitecore
One server for SharePoint (assuming it is a single farm server)
One server for Sitecore (assuming you can handle search/indexing altogether)
This is the best and the safest, since IIS is the tug of war if both SharePoint and Sitecore reside on the same server, on the scenario above SQL Server can deal with both on the same instance if you don't mind access restrictions/security, but it is better to go on distinctive instances, will be safer and easier to administer
The second scenario: 2 SERVERS
SQL Server with two instances, segregating SharePoint and Sitecore
One server for SP + Sitecore
Yes you can have both but you will need to configure ports, sites, application pools and hardware requirements very carefully.
Some considerations:
Microsoft has made clear how SharePoint should be configured, you need a dedicated machine for SQL Server, anddifferent SharePoint servers according to their specific roles in a farm: Web Front End, Application Server, Search Server, etc. or if it is a very small "farm", you can cram all of them into one server but the SQL Server (this is where disk I/O is the king of the hill).
While Sitecore doesn't not need a farm like SharePoint it shares the same similarity, a dedicated server for SQL Server, one server for Sitecore and in some cases you will like to have another server for Search and Indexing.
The bottom line here is, all depends on how big is your project, and size here is measured in the number of factors: number of users, simultaneous users, volume of data stored.
I would not mix SharePoint and Sitecore on the same machine but I would not mind at all to mix them in the same SQL Server in different instances, the reason is simple, SharePoint is more likely to take a hold of IIS, assuming you are running SP 2010/2013, the User Profile Service and the FIM are a common cause of trouble in the SharePoint realm, and it is common for SP Admin to perform IISRESET -NOFORCE to troubleshoot cases like these.
If you are using Sitecore + MVC or MMVC, you might end up customizing the IIS Sites with some heavy loads and you will need to beef up the machine to not bring SharePoint down (assuming the SharePoint Central Admin and SharePoint Web Services + additional User Web Applications you have created) are all there installed on the same server.
I'm trying to not make this overly complicated but sharing some real world scenarios because it all boils down to the load on the server, you need to remember one thing, SharePoint is a beast and it is the one that will need more resources if you want a Single SharePoint Server + Sitecore living on the same place, got it?
The recommendation from both Microsoft and Sitecore is clear: dedicated servers, and anything beyond this is at your own risk.
I've mixed and placed both together, it worked for me but I wouldn't do this again, it is not worth if have the chance to keep them apart.
I agree with Dr. Sushi on all his points. One other thing to consider is the Sitecore licensing limitations. If you are using a persistent license (a.k.a. server license) most of them limit you to 8 cores on the server. If you are running both Sitecore and Sharepoint on the same server you might need to go beyond 8 cores to handle production load, which means now you have to buy multiple licenses for Sitecore for that single installation, or you have to switch to a subscription licensing model.
From answers to other questions (such as this question), it sounds like different instance sizes offer different network throughput. My processing is I/O bound, and I'm trying to use web jobs to do it on a web site instance. Do web sites offer the same bandwidth as VMs with the same size/price point? Or if I need bandwidth higher than 100 Mb/sec, would I need to choose a solution other than web sites to do this processing?
Thanks,
David
Unfortunately, the bandwidth limits are not currently exposed.
At the end of the day, Azure App Service is using some Cloud Services machines and the bandwidth should be quite similar than in Web/Worker roles.
However, the requests go through different mechanisms (IIS ARR for example) but it might not add so much overhead.
That being said, the best way would be to try and scale out (using multiple instances) if you need more.
I hope this helps!
Adding to #dmatson answer a small detail - right now, expect SLA for high availability, which means that you can have different numbers sometimes. You will need to wait for the official release of SLA - or scale out by the size or amount. The very good FAQ i have found on that topic is here, many networking-related questions are covered.
https://blogs.msdn.microsoft.com/igorpag/2014/09/28/my-personal-azure-faq-on-azure-networking-slas-bandwidth-latency-performance-slb-dns-dmz-vnet-ipv6-and-much-more/
How many instances do I need to configure to ensure that my site stays available during planned maintenance performed on the underlying OS/VM.
I understand the availability model for web roles, but I am not clear if it is the same for web sites on Azure.
With web roles, you have to configure at least 2 instances in separate upgrade domains to get the SLA from Microsoft and to ensure that your site is routinely available. This ensures that your site will stay available as Microsoft performs maintenance on the underlying OS (updating to a newer version of the OS image, etc).
What's the equivalent story for web sites? Do I need to have two instances of my web site or does Microsoft proactively move my site to a new VM before they perform maintenance (since web sites are more "managed" than web roles, that seems like it may be possible that they do this)?
Does the answer change between Free, Shared, and Reserved web sites?
Note, I understand that during sudden, unplanned downtime, having a single instance means my site will be unavailable until it is restarted on a new node. I am not worried about that for my low-volume hobby site. What I am more interested in is the routine, planned maintenance activities that are much more common than unplanned failures of the VM or host hardware.
Edit for clarification: Clearly, having 2 (or more) reserved instances is going to be the best option for high availability, but that is cost prohibitive for a hobby site at just short of $120 per month. My question really is if a single Shared or Reserved instance is going to have routine downtime for planned maintenance. I'm specifically wondering if anyone has concrete information on this (from a blog post I may have missed or from a phone call with the Microsoft support guys, etc). Maybe the answer is "no one knows because Microsoft hasn't clarified how things will work outside of the preview yet".
I also don't want to get hung up on the term "High Availability". I guess I am just looking for "Not Low Availability". It's just a hobby site, after all.
Please note that Azure Web Sites are still in preview. That means that there is no SLA what so ever. When the Web Sites come out of preview, I would suggest having at least 2 reserved instances for high-availability.
Both Free and Shared instance imply usage quotas - CPU/Memory/Bandwitdth (Shared has no quota on the bandwidth, but still apply quota on CPU and Memory).
Having usage quotas in place is controversial to High Availability in my understanding for that term. That's why I suggest Reserved. It is same for the number of instances.
There is no SLA since Web Sites are still in preview, but I also wondered about downtime during updates and found an explanation on twitter from a member of the Azure team:
https://twitter.com/nirmsk/status/342087643779198977
Apparently they keep a "buffer" of machines that are used if the current machine needs to be rebooted, crashes, or you change the scaling options (between Shared and Reserved).
Having multiple instances won't solve the problem since any change you make on one instance is automatically propagated to all other instances.
However Azure websites now supports having a staging version of your website and swapping between staging and production versions of the site. That would be ideal for your scenario. See here for more info: http://azure.microsoft.com/en-us/documentation/articles/web-sites-staged-publishing/
What is the limit of IIS 6.0? like for example if i need to host 100,000 or 200,000 websites on IIS 6.0, how many machines would i need? or is IIS7 would be a better choice in this case for some reason?
As mentioned in the comments above the scale isn't so much the number of websites you create in IIS, but how complex and how busy those sites are.
In IIS6 one website does not necessarily equate to one executing process on the server. Application pools can group multiple websites into a single executing process to group and/or isolate applications. Alternately a single app pool can spawn multiple executing processes to make better use of server hardware.
It might help if you were to provide more detail in your question about what exactly you're trying to accomplish. If you're going to be serving hundreds of thousands of sites it would probably be a good idea to partner with a hosting company, or get some assistance from someone who knows the ins and outs of IIS, or another platform in detail and has operational experience with working through large-scale hosting scenarios.
IIS7 is not radically different from IIS6 in any performance-related way; with one exception: you can run ASP.NET in a "native" pipeline mode that bypasses some processing steps. I prefer IIS7 (if I can choose) because of its manageability advantages. But like everyone else said here: the question is impossible to answer without more information.
Hosting that many websites with IIS will be cost-prohibitive in licensing fees. Most large scale web hosting is done on Linux using Apache.
I have seen on the web some domain names having prefix of ww2 or ww3 or so (ww2.somedomain.example, ww3.yourdomain.example). And these happen mostly when traveling from a page to page. What would be the reason of having such subdomains? Is there anything special about them or are they just another sub domain? I mean, are they useful in any particular context?
People running large(-ish) sites used to do this when they needed to break up the load between more than one server. One machine would be called www then the next one would be called www2, etc.
Today, much better load balancing solutions are available that don't require you to expose your internal machine naming conventions to the browser clients.
Technically, the initials before the primary domain name (e.g. the "mail" in mail.yahoo.com) can be best though of as a machine name, identifying the web server/mail server, whatever. They can also identify a group of machines (a web farm).
So the person building up that machine can call it anything they want. The initials www are a (somewhat arbitrary) convention.
Oftentimes, ww{x} is used to indicate a particular server of a set of mirrored servers. If properly configured, I could have www.mydomain.example point to my web site on a load balancer, while I could use ww1, ww2, ww3, etc to access the site guaranteed from a specific LBed server.
I can see 3 possibilities
make the browser load resources more faster. the browser would open a fixed number of connection to same domain not to load the server
they are using more then one server so they can share the load between servers
separate some content to a separate virtual host or server. some kind of organization ...
As various answers have pointed out, modern day load-balancers can balance load without having to resort to using different sub-domains for each machine. However, there is still one benefit of dividing your site into various sub-domains: maximize browser connections.
All browsers limit the number of concurrent connections to a particular host (6 for most modern browsers). If a page contains lots of assets, page-load would be slow as the browser queue those requests because of connection limit. By loading different assets from different subdomain, you get around the connection limit, speeding up page-load.
Typically it's a partitioning strategy. When sites get sufficiently large that they can't run (or run well) on a single server you then have to look at solutions for scaling the application out horizontally (ie more servers) rather than vertically (ie bigger servers).
Some example partitioning strategies are:
Certain users always use certain servers. This can be arbitrary or based on some criteria (user type, geographic location, etc);
When a user gets a session that session is assigned to a particular server (sometimes called "sticky sessions" although this can also be used where such different machines are transparent); and
Certain activities are always on certain machines.
Another common case is organizational reasons. In an extremely large company, www might be for their main marketing website. And, ww2 might be, say, for product documentation pages.
In an ideal world, all departments would share perfectly. In practise, a big company might have their (www) marketing pages managed by an external agency. Their internal (ww2) pages done by their internal team. Often, the marketing agency just doesn't update pages quickly or refuses to run certain stacks, may be too limiting in terms of bureaucratic needs.
The marketing agency may insist on controlling the www and not sharing due to past situations where a company website went down due to internal reasons and yet the agency got blamed, or vice versa.
So, theoretically, there's no need to do this with modern load balancing and such. But, in practise, it can be a lot cheaper, straightforward and allow better business productivity.