Spectrum 64 bit vs. 32 bit

[kiran_diwakar]

Hello All,

 

As we move to the next stage of work through the Spectrum 64 bit project, one thing that we are trying to scope out is support for 32 bit - our thought process is to continue only the 64 bit variant. The effort and resources to support both in parallel is humongous and after the project, we might spend most of our energies just maintaining the two streams and hence some critical thought process and hence the reach out to get some views.

 

All the OS’s Spectrum supports have both 32 and 64 bit variants and below is the minimum hardware specification for 64 bit (assuming you will load the SS with 10K devices).

 

	RAM (GB) (Occupied by processes)	CPUs
Spectro server	32	2 quad core
OC Server	32	2 quad core
OC Client	16	2 quad core

 

I know most customers would have this kind of hardware. If they want to continue to use 2K-3K devices per SS, they would still need to use 64 bit variant, albeit with lower RAM requirements (as per the guidelines of the OS vendor).

 

Any feedback/critique would be much appreciated. I am also contemplating a poll - will decide on that once I get some responses.

Regards,

Kiran Diwakar

[Stuart Weenig]

Agreed, makes no sense to have both 32-bit and 64-bit, except perhaps for the first few dot releases. Some places have standard practices about not adopting a new architecture right away, so having the flexibility of staying on the 32-bit version until the 2nd 64-bit version is available would be good. One or two dot versions of overlap should be fine. After that, dump the 32-bit version.

[Michiel Helder]

Like Stuart said, I think you should maintain both for at least a few dot releases or until the next major release. There can be policies about adopting a new architecture or limitation on the ability to plan a project for a Spectrum reinstall. Even though a new installation/migration is hardly more work than an upgrade, it is often seen as something different and other procedures have to be followed which take more time to plan and execute.

[kiran_diwakar]

Just to clarify, the latest versions (before one with 64bit) would be fully supported for atleast 18-24months (based on our policies). So customers would have a supported 32 bit version for reasonable period of time.

Regards,

Kiran Diwakar

[Stuart Weenig]

Yeah, that's not what I mean. I mean overlap. Say there was a bug in my 32-bit version and the only flavor of the next version was 64-bit. That would mean a significant change for me (if i'm on 32 bit servers) just to go to the new version.

 

Having a few dot releases that are available in both flavors would allow me to decide 1) if i want to upgrade my 32-bit version knowing that the next upgrade will have to be 64-bit or 2) if i want to go ahead and upgrade to 64-bit now.

[kiran_diwakar]

Hi Stuart,

 

The 32bit variant would be maintained and supported, we will not be able to stop it as there are 100s of customers on it.

64bit feature would be like any other capability - for getting that capability, the customers would need to move to that version of the product.

If they choose not to move for any reason, they will continue on the current release (say 9.4) and we will continue to support it in parallel as we do for any other release as per the committed lifecycle for the releases that we follow.

 

Hope that clarifies.

 

Regards,

Kiran Diwakar

[Stuart Weenig]

We'll, you asked for input. My suggestion is to not do it the way you suggest (a hard stop on the 32-bit version). I suggest releasing the 64-bit version at the same time the next 32-bit version comes out, support both for a few dot releases, then drop 32-bit support. 

[Michiel Helder]

I can understand that you don't want to do any new development on features on the 32bit version once 64bit is out, but I would expect patches to be made available on both platforms for the 18-24 months you mentioned. If that't what you mean with maintained and supported, it sounds good to me. If maintained and supported is just providing support but not doing pro-active fixes on issues that were identified on the 64bit platform, it would not be enough in my opinion.

[kiran_diwakar]

Right Michiel, it is the former. We would continue to give fixes, do cumulatives and HF (and if needed Service Packs too). Whenever we issue EOS for a release, we are mandated to give atleast 12 month advance notice. We have just given that notice for 9.2 - so we would have a lot of time

 

As I have always said, I have 1000 customers and we would ensure we are not doing drastic changes unless we have some alternate options.

 

Regards,

Kiran Diwakar

[Stuart Weenig]

kiran_diwakar, it seems like you've already made up your mind, so i'm a bit confused why you're asking for feedback about this.

 

We're asking for forward progression on the 32-bit progression even after the 64-bit version is released. We're suggesting that you obtain additional bandwidth to essentially support two products (32-bit and 64-bit) for a few versions.

 

For example (version numbers made up):

• v9.x - 32-bit only
• v9.y - 32-bit only
• v9.z - 32-bit only
• v10.0 - 32-bit and 64-bit (feature parity where possible)
• v10.1 - 32-bit and 64-bit (feature parity where possible)
• v10.2 - 32-bit and 64-bit (feature parity where possible)
• v10.3 - 64-bit only
• v10.4 - 64-bit only

[Justin_Kulikowski]

SpectroServer and OC Server system requirements look good.

 

Can you clarify the OC Client though?  I interpret this as the Java client that runs on each user's workstation.  These User workstations will not have 8 CPUs and 16GB of RAM.

[Joerg Liesenfeld]

Hi Kiran,

 

the CA Spectrum (SpectroSERVER plus OC-Server) requirements at OS level may not become a road-blocker. Spectrum is available on Windows-Server OS (here at least on 2008 or higher) - and for Linux in RedHat 5.x or higher - plus Solaris 9 or higher. These all will cover by default the 64bit execution environment. There is no default option for Windows2008(++), Redhat 5.4(++) or Solaris 9(++) to install 32bit only OS-execution layer. At this point all todays available OS-requirement platforms for CA Spectrum at server level will support the 64bit. At workstation level to run the OC-Console application this is truly different and here 32bit flavours of different OS are maybe available and used by many. But I feel here the 32bit moves away within next years.

 

For the Servers the hardware requirement is high - but for the workstation the requirement looks very high and is challenging. This is because todays Win7 or Win8 is running fine at 4GB RAM - with 2 or 4 cores. Adding up to 8GB RAM for a workstation is then no "hardware" limit (for most of all used workstation hardware today) - but running at more then 4 cores(physical) is exceeding standard hardware. Mainboards capable with 2 sockets for quad-core CPUs are in the region of server-hardware/boards.

 

Regards, Joerg

[Maik Seckler]

Hi Kiran,

 

regarding the amount of required RAM for OneClick Clients, I second JLie. 16GB seems absurdly high to me, and also the 2 quad-core CPU. I would expect one quad-core to suffice and also consider that we probably don't want to claim all CPU / RAM resources for the OneClick Client. The user needs to be able to use his/her machine for other tasks as well.

 

Regards

Maik

[kiran_diwakar]

Hi Maik, Joerg,

 

Completely understand your sentiment. But please note that the above numbers are recommended if you have a bunch of landscapes and if you are going to access 12K devices, their topology, data, events/alarms etc from the system. So the OC client would be recommended that kind of specs for optimal performance.

If load is normal, then your current specs should be fine too.

 

I will have the engineering team articulate this much better - the minimum and then the recommended. The above is NOT minimal Hope that sounds reasonable.

 

Regards,

Kiran Diwakar