May 13, 2009 at 8:16 am
We are considering a centralized SSIS server for all production packages rather than deploying them to each server. Has anyone else done this and what are the pros and cons?
MG
"There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies."
Tony Hoare
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair.
May 13, 2009 at 8:23 am
Problems are:
Can the centralised server see all the servers which the packages need access to?
Is there going to be an issue with huge amounts of data travelling over the network. Moving data from server A to server B will now mean having to go from Server A to Centralised Server and then to Server B.
Even a transformation just within server A will now mean having to move data from the target server to the execution server and back again.
Apart from that, there are many benefits to centralising the SSIS packages. So if the bulk testing works out OK then go for it 🙂
May 13, 2009 at 8:29 am
Samuel took the words out of my mouth, or should I say the keystrokes out of my fingers.
We've done that here with DTS. One thing that we do to minimize network traffic is to do all processing on the DTS server The network traffic is then reduced to pulling data from the source, and pushing data to the final destination. This works ok for us and the type of packages were running. It would not work that well for something like a data warehouse build involving multiple servers.
For best practices on asking questions, please read the following article: Forum Etiquette: How to post data/code on a forum to get the best help[/url]
May 13, 2009 at 8:31 am
Can the centralised server see all the servers which the packages need access to?
Yes
Is there going to be an issue with huge amounts of data travelling over the network.
The packages will be replacing processes that currently move large amounts of data so that won't change. What will change is that all the packages will be centralized so hopefully easier to manage. The current processes live on a variety of application servers which makes management a pain.
Thanks for your input. It is appreciated.
MG
"There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies."
Tony Hoare
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair.
May 13, 2009 at 8:35 am
One thing that we do to minimize network traffic is to do all processing on the DTS server The network traffic is then reduced to pulling data from the source, and pushing data to the final destination.
This is what we plan to do also.
Thank you both for your input. It reinforces my thoughts on the subject 😀
MG
"There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies."
Tony Hoare
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair.
May 13, 2009 at 8:36 am
You're welcome and keep us posted on how it works out.
Good luck.
For best practices on asking questions, please read the following article: Forum Etiquette: How to post data/code on a forum to get the best help[/url]
May 13, 2009 at 8:37 am
Will do
MG
"There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies."
Tony Hoare
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair.
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply