Showing posts with label 2-node. Show all posts
Showing posts with label 2-node. Show all posts

Sunday, March 25, 2012

Analysis Service in cluster

Hi
I have 2-node active/active cluster. I have installed 2 SQL instances (one
per node).
Now I want to install Analysis service in cluster for datawarehouse . I have
some questions regarding this.
1. Should I have seperate cluster group to be created for this? if so, how
many disk drives would be required for that group (recommendations).
2. Should I give different instance name for analysis serviceor I can be
same instance name as SQL instance.
Thanks and Regards,
Vijay
Vijay
1. Create a separate cluster groups and add Disk to it ... I would start
with one disk or more depending on how you have laid out the DW
2. For the instance - I would recommend a different name
Thanks
"Vijay" <Vijay@.discussions.microsoft.com> wrote in message
news:16D83565-9F15-4A5D-A745-B2C47EE0BF5F@.microsoft.com...
> Hi
> I have 2-node active/active cluster. I have installed 2 SQL instances (one
> per node).
> Now I want to install Analysis service in cluster for datawarehouse . I
> have
> some questions regarding this.
> 1. Should I have seperate cluster group to be created for this? if so,
> how
> many disk drives would be required for that group (recommendations).
> 2. Should I give different instance name for analysis serviceor I can be
> same instance name as SQL instance.
> Thanks and Regards,
> Vijay
>
|||Thanks for your help
"Seme Rollansa" wrote:

> Vijay
> 1. Create a separate cluster groups and add Disk to it ... I would start
> with one disk or more depending on how you have laid out the DW
> 2. For the instance - I would recommend a different name
> Thanks
>
> "Vijay" <Vijay@.discussions.microsoft.com> wrote in message
> news:16D83565-9F15-4A5D-A745-B2C47EE0BF5F@.microsoft.com...
>
>

Thursday, February 9, 2012

Alternative to IPSec?

The client I'm working with has a 2-node Failover cluster. Owing to their
environment, they have several machines accessing the many databases. For
cost reasons, they went with SQL standard.
As to securing the traffic. I understand that IPSec isn't supported for
failover cluster, owing to the recovery time (6 minutes, according to the
document).
But the recovery for SQL standard doesn't allow external connections until
all databases are recovered. If the server has a lot of databases (perhaps
50), there may already be a delay.
I guess the questions I'm asking are:
1>Outside of the time delay, is there any other reasons to avoid IPSec?
2>In an environment with a lot of potential clients, what are the
recommended alternatives?
Thanks for any insight!
Bob Coppedge
me (at) RLCoppedge (put a dot here) com
IPSec can be processor intensive; so, offloading the encryption to an
outside engine would increase throughput. This could be through a support
NIC with these features, or a dedicated hardware appliance.
Short of that, you could use SSL encryption and/or HTTPS for communication.
Microsoft provides a good document on the subject through MSDN:
http://www.microsoft.com/downloads/details.aspx?displaylang=en&familyid=055ff772-97fe-41b8-a58c-bf9c6593f25e
Good luck.
Sincerely,
Anthony Thomas

"RL Coppedge" <RLCoppedge@.hotmail.com.(nospam)> wrote in message
news:28CF43D3-38DC-47A8-9C46-CC25D1A01150@.microsoft.com...
> The client I'm working with has a 2-node Failover cluster. Owing to their
> environment, they have several machines accessing the many databases. For
> cost reasons, they went with SQL standard.
> As to securing the traffic. I understand that IPSec isn't supported for
> failover cluster, owing to the recovery time (6 minutes, according to the
> document).
> But the recovery for SQL standard doesn't allow external connections until
> all databases are recovered. If the server has a lot of databases
(perhaps
> 50), there may already be a delay.
> I guess the questions I'm asking are:
> 1>Outside of the time delay, is there any other reasons to avoid IPSec?
> 2>In an environment with a lot of potential clients, what are the
> recommended alternatives?
> Thanks for any insight!
> Bob Coppedge
> me (at) RLCoppedge (put a dot here) com
>