Redundant license servers: more risk of failure instead of more safety?

[willers]

Hi,
Testing the robustness of three redundant SPSS license servers we damaged
the system so hard, that we needed one day work to get it work again. And
even now the situation is not satisfactory. We were glad, that this happened
in the testing phase. During normal work it would be a great disaster.

What we did:
We established successfully three redundant servers. To test the reliability
we finished the service completely on that server working as leader. The
licenses were passed correctly to the second server in the hierarchy. In the
second step this computer was rebooted and the leader started again.
Thereafter the information about licenses was completely lost. Nobody got a
license. In the administration tool the servers were shown in the in the
initial state without any licenses. After several useless trials we shut
down all servers and redistributed the original redundant license file
'lservrllf'. After that the servers worked again und distributed licenses,
but the licenses where allocated to the second server in the hierarchy and
stayed there. Stopping this server the licenses where not passed to any of
the other tow servers. No licenses were distributed, when this server was
stopped. Stopping one of the two others had no impact. So we lost
redundancy.

Our design:
Within our LAN two subnets A and B are to be served with SPSS 16. The
leading server is located in subnet A', which is physically identical with
A. The other two are in Subnet B. The leader run under Windows Server 2003,
the other two use WinXP. No Windows firewalls are used. On all computers
except the second one only the SPSS license server was installed
additionally to the system software. On the second computer an other license
server is also running using software from Aladdin. The university firewall
was opened for UDP 5093 und TCP 5099. The SPSS-documentation requests UDP
5099, but this port is shown as closed and no traffic was reported on this
port. Instead the servers talked on port TCP 5099 and UDP 5093 LSHOST and
etc/hosts are defined on all servers. All servers use the Sentinel-server
8.1.

After this experience we have lost the confidence in the safety of redundant
SPSS license servers. Such damage, we observed should be impossible.
Apparently the communication of the servers is not protected against all
unattended interrupts. But this is not the only thing, which got us
thinking. There is no tool in the SPSS license server to control the
conversation of the servers. Therefore it is very difficult to locate an
error. But such an error is critical, since all the users are affected. And
thirdly a reset after a serious damage seems to be to complicate, to be
incorporated in an emergency plan. Therefore we think that in the present
implementation redundant servers give not the protection, we need.

What is your opinion? Have you quit different experiences?

=====================
To manage your subscription to SPSSX-L, send a message to
[hidden email] (not to SPSSX-L), with no body text except the
command. To leave the list, send the command
SIGNOFF SPSSX-L
For a list of commands to manage subscriptions, send the command
INFO REFCARD

[Weeks, Kyle]

Reinhart,

These types of issues should really be reported to Tech Support for diagnosis.  There are often IT configuration issues that can lead to these types of issues.

Regards.

Kyle Weeks, Ph.D.
Director of Product Management, SPSS Product Line
Product Management
SPSS Inc.
[hidden email]
www.spss.com
SPSS Inc. helps organizations turn data into insight through predictive analytics.


-----Original Message-----
From: SPSSX(r) Discussion [mailto:[hidden email]] On Behalf Of Reinhart Willers
Sent: Sunday, December 16, 2007 1:16 PM
To: [hidden email]
Subject: Redundant license servers: more risk of failure instead of more safety?

Hi,
Testing the robustness of three redundant SPSS license servers we damaged
the system so hard, that we needed one day work to get it work again. And
even now the situation is not satisfactory. We were glad, that this happened
in the testing phase. During normal work it would be a great disaster.

What we did:
We established successfully three redundant servers. To test the reliability
we finished the service completely on that server working as leader. The
licenses were passed correctly to the second server in the hierarchy. In the
second step this computer was rebooted and the leader started again.
Thereafter the information about licenses was completely lost. Nobody got a
license. In the administration tool the servers were shown in the in the
initial state without any licenses. After several useless trials we shut
down all servers and redistributed the original redundant license file
'lservrllf'. After that the servers worked again und distributed licenses,
but the licenses where allocated to the second server in the hierarchy and
stayed there. Stopping this server the licenses where not passed to any of
the other tow servers. No licenses were distributed, when this server was
stopped. Stopping one of the two others had no impact. So we lost
redundancy.

Our design:
Within our LAN two subnets A and B are to be served with SPSS 16. The
leading server is located in subnet A', which is physically identical with
A. The other two are in Subnet B. The leader run under Windows Server 2003,
the other two use WinXP. No Windows firewalls are used. On all computers
except the second one only the SPSS license server was installed
additionally to the system software. On the second computer an other license
server is also running using software from Aladdin. The university firewall
was opened for UDP 5093 und TCP 5099. The SPSS-documentation requests UDP
5099, but this port is shown as closed and no traffic was reported on this
port. Instead the servers talked on port TCP 5099 and UDP 5093 LSHOST and
etc/hosts are defined on all servers. All servers use the Sentinel-server
8.1.

After this experience we have lost the confidence in the safety of redundant
SPSS license servers. Such damage, we observed should be impossible.
Apparently the communication of the servers is not protected against all
unattended interrupts. But this is not the only thing, which got us
thinking. There is no tool in the SPSS license server to control the
conversation of the servers. Therefore it is very difficult to locate an
error. But such an error is critical, since all the users are affected. And
thirdly a reset after a serious damage seems to be to complicate, to be
incorporated in an emergency plan. Therefore we think that in the present
implementation redundant servers give not the protection, we need.

What is your opinion? Have you quit different experiences?

=====================
To manage your subscription to SPSSX-L, send a message to
[hidden email] (not to SPSSX-L), with no body text except the
command. To leave the list, send the command
SIGNOFF SPSSX-L
For a list of commands to manage subscriptions, send the command
INFO REFCARD

=====================
To manage your subscription to SPSSX-L, send a message to
[hidden email] (not to SPSSX-L), with no body text except the
command. To leave the list, send the command
SIGNOFF SPSSX-L
For a list of commands to manage subscriptions, send the command
INFO REFCARD

[Kylie Lange]

Hi all,

My organisation is considering moving from stand-alone installations to
a network license. We may have a test system up in February (of 3
license servers). I am also keen on hearing of other people's
experiences with SPSS network licenses, good or bad.

Thanks,
Kylie.


On 17/12/2007 5:46 AM, Reinhart Willers wrote:

> Hi,
> Testing the robustness of three redundant SPSS license servers we damaged
> the system so hard, that we needed one day work to get it work again. And
> even now the situation is not satisfactory. We were glad, that this happened
> in the testing phase. During normal work it would be a great disaster.
>
> What we did:
> We established successfully three redundant servers. To test the reliability
> we finished the service completely on that server working as leader. The
> licenses were passed correctly to the second server in the hierarchy. In the
> second step this computer was rebooted and the leader started again.
> Thereafter the information about licenses was completely lost. Nobody got a
> license. In the administration tool the servers were shown in the in the
> initial state without any licenses. After several useless trials we shut
> down all servers and redistributed the original redundant license file
> 'lservrllf'. After that the servers worked again und distributed licenses,
> but the licenses where allocated to the second server in the hierarchy and
> stayed there. Stopping this server the licenses where not passed to any of
> the other tow servers. No licenses were distributed, when this server was
> stopped. Stopping one of the two others had no impact. So we lost
> redundancy.
>
> Our design:
> Within our LAN two subnets A and B are to be served with SPSS 16. The
> leading server is located in subnet A', which is physically identical with
> A. The other two are in Subnet B. The leader run under Windows Server 2003,
> the other two use WinXP. No Windows firewalls are used. On all computers
> except the second one only the SPSS license server was installed
> additionally to the system software. On the second computer an other license
> server is also running using software from Aladdin. The university firewall
> was opened for UDP 5093 und TCP 5099. The SPSS-documentation requests UDP
> 5099, but this port is shown as closed and no traffic was reported on this
> port. Instead the servers talked on port TCP 5099 and UDP 5093 LSHOST and
> etc/hosts are defined on all servers. All servers use the Sentinel-server
> 8.1.
>
> After this experience we have lost the confidence in the safety of redundant
> SPSS license servers. Such damage, we observed should be impossible.
> Apparently the communication of the servers is not protected against all
> unattended interrupts. But this is not the only thing, which got us
> thinking. There is no tool in the SPSS license server to control the
> conversation of the servers. Therefore it is very difficult to locate an
> error. But such an error is critical, since all the users are affected. And
> thirdly a reset after a serious damage seems to be to complicate, to be
> incorporated in an emergency plan. Therefore we think that in the present
> implementation redundant servers give not the protection, we need.
>
> What is your opinion? Have you quit different experiences?
>
> =====================
> To manage your subscription to SPSSX-L, send a message to
> [hidden email] (not to SPSSX-L), with no body text except the
> command. To leave the list, send the command
> SIGNOFF SPSSX-L
> For a list of commands to manage subscriptions, send the command
> INFO REFCARD
>

=====================
To manage your subscription to SPSSX-L, send a message to
[hidden email] (not to SPSSX-L), with no body text except the
command. To leave the list, send the command
SIGNOFF SPSSX-L
For a list of commands to manage subscriptions, send the command
INFO REFCARD