Our configuration is like this:
Two web app servers in NLB cluster with shared IIS configuration
Two DB servers in DB cluster
Session is stored in database
When we test our clusters, if we shut down one app server and one DB server, user session is not preserved and user is redirected to the login page.
If we shut down only one DB server, session is preserved.
Do you have any idea what could be the cause of this behaviour?
Could it be something related to the IIS shared configuration?
Related
I have 2 load balanced web servers. My application is using the SQL Server Session State database on SQL Server 2008.
The 2 web servers are identical in terms of IIS configuration, and if I understand correctly, the two web apps on the two servers will be mapped to the same app id in the ASPStateTempApplications table since they have the same IIS configuration. So, counting the number of sessions associated with this app Id (from the ASPStateTempSessions tabel) will result in the total count of sessions on the two web servers together.
My questions is:
Is there a way to know how many sessions are active on each server individually?
I have the problem that when I take one server out of the load balance, I want to know if there are still any active sessions on the server or not before recycling it.
Another scenario, if I have to recycle the IIS on one of the servers because another web app on the same server is crashing, I would like to know how many sessions will be affected when I do so.
Thanks.
Basically, they all may and actually SHOULD be active on both ) Because in this mode sessions are not bound to the web-servers at all.
You can stick each user to a single server with load-balancing techniques on your gateway and if so - better to use InProc mode with all its benefits )
Since the session data is stored in SQL Server, you shouldn't have to worry about how many sessions are active. Once the server is shutdown (or IIS is recycled, depending on the configuration), the load balancer will automatically send any new requests to the active IIS server. With the session data stored in SQL, the active server can retrieve the session data and the user will be unaware that any server switching has occured.
Ideally, you should test this procedure periodically to make sure everything is configured correctly. Also, you should follow this procedure when installing patches to the servers.
I have a Web application made in ASP.NET and MS SQL 2005 as database
ASP.NET Web App is hosted on : http://192.168.0.90
and MS SQL Server DB on : 192.168.0.91
User use url : http://192.168.0.91 to access the server.
MY DR IP address for Web App http://192.168.0.150 and Database is : 192.168.0.151
Suppose my Web Server Fails. i need to Automatically divert user to my Web Application DR Server IP
same with DB Server.
without user knowing it ? how can i do it...
Waiting for your earliest revert.
Regards
Hasnain
preferred is the process should be automatic
For the web application use DNS instead like myapp.domain.com and assign two IPs (A records) to it. It will be working as round-robin load balancing and when one server will crash, it will direct you to the another one. This is the simplest yet quite effective method providing some extra availability, assuming you have session in external database or you are using clustered storage.
Also, when one of your webservers is not available, you can dynamically remove it's IP from the DNS, and this DNS A record should have 300 seconds TTL.
I'm completely stuck with this version 1.0.0.0 product.
I'm running in a domain environment but for the specific application i'm using I want to disable security to reduce the workload on the servers when accessing the cache.
I've got a bunch of web servers with an existing application using SQL sessions state, and the idea was to roll out AppFabric and use the session state provider and a fast solution to speed things up. Currently have a single separate server running appFabric Host.
All Servers are on the same domain.
I've got AppFabric Running using this mode on the host
Set-CacheClusterSecurity -ProtectionLevel EncryptAndSign -SecurityMode Transport
Local App Pool on the web servers is using NETWORK SERVICE account, and i've grantedthe machine accounts permissions and it all works fine.
But then on the server i set this
Set-CacheClusterSecurity -ProtectionLevel None -SecurityMode None
(Stopping and Starting the cluster).
Then after that I get this error.
ErrorCode:SubStatus:There is a temporary failure. Please retry later. (One or more specified Cache servers are unavailable, which could be caused by busy network or servers. Ensure that security permission has been granted for this client account on the cluster and that the AppFabric Caching Service is allowed through the firewall on all cache hosts. Retry later.)
My assumption is that the client (session state provider), is set by default to use security and need to be set not too, but can't find any doco on how to change this, or i could be barking up the wrong tree.
Any help would be appreciated.
Thanks,
Joel
You can configure the client security setup in your web.config by adding a securityProperties element under the dataCacheClient element e.g.
<dataCacheClient>
<hosts>
...
</hosts>
<securityProperties mode="None" protectionLevel="None" />
</dataCacheClient>
There's a complete reference for the client configuration settings here.
Our website connects to a database correctly when running the website locally using the built-in web server. But, when we deploy the site to our server running IIS, we get a database connection error. The database server is different from our IIS server. Note that a trusted connection to a different database on the SAME server as IIS works fine.
What do we need to do to connect to a SQL database on a different server with a trusted connection?
When you're running a web site using Cassini, the account used by the web server process is your own account that you use to log on to your Windows machine. That account will be different on IIS.
Consider the security implications of opening the database up to a broader access than you may need with trusted connection. Perhaps you could use Windows authentication with a service account. That is, create an application-specific user in SQL Server with limited permissions. Then, you will get the benefits of connection pooling while avoiding passing credentials.
I'd check the user account that app domain in IIS is using to connect to SQL Server. The account in IIS may not have access to network resources as well which would explain the trouble reaching the other database server.
Sounds like you need to configure the database server to provide access to the database you're trying to connect to.
Assuming SQL Server, log into SQL Server Enterprise Manager and under Security -> Logins, open the properties for the applicable user (probably the Network Service or ASP.NET account of the web server) and go to the Database Access tab and ensure that the Permit checkbox is ticked for the database you are connecting to.
I have an asp.net application that should access data from two SQL Servers. One of the SQL Servers is present on the same machine as IIS (let us call it SQLSERVER1) whereas the other SQL server is present on another machine (SQLSERVER2).
The connection strings are trusted for both the SQL servers. Impersonation has been set to true in my web.config file. I am using Windows authentication in both IIS and web.config.
When I try to access data from SQLSERVER2, I get login failed for user(null) error. The user through which I have logged in through Windows exists as a SQL server account in SQLSERVER2.
What could be the possible reason?
NOTE: This is a newbie question IMHO.
NOTE: The IIS used is 6.0 (Windows 2003). It is not set to IIS 5.0 isolation mode.
EDIT:The user getting impersonated is a domain user
Addition:
I also want to state that I get this error message when I access it as a client of the server where IIS is running. In other words, let me say I am working on machine A, the IIS and SQLSERVER1 are on machine B, and SQLSERVER2 is on machine C.
I do not get this error message when I am working on machine B. This is stumping me more.
This is absolutely a delegation problem. As one person pointed out, you need to make sure Kereberos authentication is being used. The old style NTLM isn't going to cut it. Here's more on Kerberos vs. NTLM.
In a nutshell, if you have a webserver and a database and you want the webserver to impersonate the user when making database requests (so that you can set up permissions on the database directly on a per-user or user-group basis) you're performing a double-hop. Credentials must past first from the user's computer to the webserver and again to the database. As you can imagine, the database has to trust the webserver to "do no evil" or this could be an extremely dangerous security hole. As a result, you have to set up what is called in the Windows Server world "delegation"...
Microsoft has a good article about all this here. Further, you can look over an article like this to get an idea of how to set it all up. We've run into this frequently, and it can be a pain at first, especially since as a developer you're probably not in control of the servers directly (especially production ones) and you'll have to spend a lot of time with the server guys down the hall.
You're probably running into this problem because non-Kerberos based impersonation (NTLM) is only valid on the local machine (the webserver). If you want to be able to use those credentials to access another machine, you're going to need to make sure you're using Kerberos.
Try this: http://support.microsoft.com/kb/810572
Your authentication to the webserver is not passed through to the sql server. The web server is authenticating to the SQL Server using the account that your application pool is running under.
You should check that the machine account for SQLSERVER1 has trusted for delegation enabled. Otherwise SQLSERVER2 won't trust the impersonation running on SQLSERVER1. This is in addition to confirming that Kerberos is used to set up the impersonation in the first place. This also assumes that the servers and the users are all members of the same domain.
BTW, are sure you want to do things this way, you end up creating a lot more connections because they end up being unique to a user?
Have you tried to access the database on server2 using SQL SErver administrator from Server1 and made a successful connection?
If not then this could be because by default SQL Server installs itself with tcp turned off by default.
You will need to make sure that this is turned on for server2 to allow server1 to connect.
server1 has no problems connecting due to the fact it can use the shared memory connection.