Add New Server with Configtool Questions

Question

Hello All,
We are running EP7 SP12 on W2K3 with 16GB RAM and 4 CPUs.
As part of one the Go Live checks done to the system a while back, it was recommended that we increase the number of Server processes to the instance.
So, I followed the information here (http://help.sap.com/saphelp_nw70/helpdata/en/68/dcde416fb3c417e10000000a155106/frameset.htm) to add 3 additional servers to the instance.  When I restarted the J2EE engine, it basically sat there in a 'Starting Apps' status.  I waited about 2 hours before I stopped the startup process.  I went back into Configtool and did a 'Remove Server' on the last, Server3, process and restarted J2EE.  This time, everything did start OK, but now I have a few questions I hope someone can answer.
1.  Is there a limit to the number of Server processes that can exist in a single instance?  If not, what would cause the J2EE servers to essentially hang on startup although they didn't look hung, just extremely slow starting up.
2.  I thought when you did the initial 'Add Server' it was supposed to create a duplicate Server process.  But, when I check the directory structures of the newly created Server processes, they aren't anywhere close to being the same as the original Server0 process.  For example, we have a custom redirect in place when people logon to the Portal, but this wasn't transferred/copied to the new Server1 or Server2.  The same was true for other customizations.  Also, when looking at the structure, Server0 has approx 80,000 files and 15,000 sub-folders.  When looking at the new Server1 & Server2, they are both different in size in both files and folders in respect to each other and compared to Server0.  Shouldn't they all be the same?
3.  A follow up to question 2.  If they aren't the same and they are supposed to be the same, can we just copy the missing files & folders from Server0 to the new Servers?
4.  Lastly, since I did a 'Remove Server' in Configtool for Server3, it does not appear in the MMC when the J2EE engine starts.  This I expect.  But, it did not remove the directory structure for Server3.  If I try to manually delete the Server3 directory, it simply says it is in use and won't let me delete the structure.  So, is it safe to delete this structure since it isn't being used anymore?  If so, I'll stop SAP and delete the structure offline.  Do I have to do any database cleanup once I do this?  If so, can someone point me to some documentation as to what needs to cleaned up in the DB and how?
Thanks,
Tom

Answer 1

Thanks for the info.
Interesting though.  I open a message with SAP and posed these same questions.  Their response was similar to yours, but it opened up a whole new set of questions.  What follows is the text of that message for others to benefit from (clipped for clarity):
SAP's response to the original set of questions posted here:
=====================
....1.Number of server nodes depends upon the CPU speed.J2EE Engine
can support upto 21 server nodes in a intance.
If number of server nodes is big,it will slow down the startup process.
2.When you create the "New Server"its not the dublicate server.
Its a new server.You can not copy mising files from one server to other
J2EE engine syncronises the server nodes in the instance.
3.Yes.You need to manually delete the file system.Configtool deletes
the server node from the DB....
=====================
To which I replied:
=====================
.....2. I thought when you did the initial 'Add Server' it was supposed to
create a duplicate Server process. But, when I check the directory
structures of the newly created Server processes, they aren't anywhere
close to being the same as the original Server0 process. For example,
we have a custom redirect in place when people logon to the Portal, but
this wasn't transferred/copied to the new Server1 or Server2. The same
was true for other customizations. Also, when looking at the structure,
Server0 has approx 80,000 files and 15,000 sub-folders. When looking at
the new Server1 & Server2, they are both different in size in both
files and folders in respect to each other and compared to Server0.
Shouldn't they all be the same?"
You replied:
"2.When you create the "New Server"its not the dublicate server.
Its a new server.You can not copy mising files from one server to other
J2EE engine syncronises the server nodes in the instance."
But, from actual experience, it does NOT synchronize the nodes, rather
it is a partial synchronization.
So, are the following staements true:
-When a new server process is added, ONLY standard SAP delivered files
& folders are synchronized. True or False?
-No custom files/folders are synnchronized. True or False?
-Custom values, whether part of standard SAP deliverables or custom
deliverables, are NOT synchronized. True or False?
-Each server node needs to be configured independently. True or False?
The reason I'm asking such specific questions is because of what we are
seeing. I'll use the same example from before. We modified the
index.html file for the Portal in Server0. When we added the new
server nodes, this index.html file was not synchronized. Instead, the
default index.html file was created for the new server nodes. That is
an example at the file level. Here is an example from a configuration
perspective. In Server0, in the Visual Admin tool, we have a TREX
server specified in TREX service properties. When the new server nodes
were created, this setting was NOT transferred. Therefore, TREX didn't
work until I specifically went back into VA and added the TREX settings
to the new server nodes. This is a major problem and opens up three
more questions:
1.How do we know what settings were transferred vs. those that weren't
transferred?
2.Also, if you can't copy missing files/folders from one server to
another, then how are we supposed to get those files/folders into the
new server(s)?
3. Is there a way to do a comparison between the server nodes to see
what settings are missing?.....
=====================
SAP's reply:
=====================
.....-When a new server process is added, ONLY standard SAP delivered files
& folders are synchronized. True or False? TRUE
-No custom files/folders are synnchronized. True or False? TRUE
-Custom values, whether part of standard SAP deliverables or custom
deliverables, are NOT synchronized. True or False? TRUE
-Each server node needs to be configured independently. True or False?
YES.
If any new server node is added,J2EE Engine syncronises the information
at the time of next restart......
======================
My Reply:
======================
.....1.How do we know what settings were transferred vs. those that weren't
transferred?
2.Also, if you can't copy missing files/folders from one server to
another, then how are we supposed to get those files/folders into the
new server(s)?
3. Is there a way to do a comparison between the server nodes to see
what settings are missing?.....
======================
SAP's Reply:
======================
.....1.How do we know what settings were transferred vs. those that weren't
transferred?
NO there is no way.
2.Also, if you can't copy missing files/folders from one server to
another, then how are we supposed to get those files/folders into the
new server(s)?
You need to deploy the appliactions again on the new server.
3. Is there a way to do a comparison between the server nodes to see
what settings are missing?
No there is no way......
======================
So, although I really didn't have the answers I was looking for, I confirmed the message.  It seems ludicrous to me that there is no way of doing a comparison or manual synch between two server nodes.  Also, I can't believe you have to configure each node independently let alone when you do a deployment you now have to deploy to each server individually, of which I haven't found any docs explaining how to do that.  So if someone here has a suggestion I'd appreciate it.  Although at this point, given the fact the server nodes are so out of synch as to make them almost unusable, we might just delete them all and go back to one node, although I don't want to have to do that.
Thanks,
Tom