bloxHub

www.infoblox.com/community
7 posts / 0 new
bloxTools in NIOS 6

What's the stance of redundancy for bloxTools in NIOS 6?

In NIOS 5 we were told our data would be replicated to Grid Master Candidates automatically so that if the Grid Master were to go down we wouldn't loose any data.

In NIOS 6 bloxTools runs on a Member and NOT on a Grid Master.  Is data automatically sync'd/backed up anywhere so that when the Member running bloxTools is lost one can restore it on another Member without loosing data (or with a minimal loss)?

Also, are there any plans to increase access to bloxTools to include SSH access and perhaps give root access?  It's so painfully difficult to troubleshoot code running on bloxTools.

Also, it appears the maximum memory one can allocate to bloxTools is still low - 1024mb for the high end appliances (which are very expensive), going lower for the lower spec appliances.  Why is the memory limited so?  And the disk space for that matter, is also limited to 4gb, this also seems low?

+1
0
-1
Tags
Automation Change Manager
Re: bloxTools in NIOS 6

 

In NIOS 6, with the bloxTools Environment configured to run on an HA member, you still get redundancy.

About the replication to the Grid Master Candidate, you still get the replication of the bloxTools environment configuration (enabled/disabled, ftp port, etc.). However, the bloxTools Environment files (your snapins and their data) are only replicated to the hosting HA member pair. If you do not have an HA member, you will have to rely on periodic backups, which will include a copy of the bloxTools Environment. Does this level of redundancy and replication meet your needs?

Regarding root access to the bloxTools Environment, keep in mind that the bloxTools environment is designed to be a hosting environment. Snapin development should be done off-box. There are a number of facilities to help you troubleshoot snapins, as discussed in the Tool Time blog and other posts. Short of granting your root access, what else can we do to help you troubleshoot and debug snapins?

Finally, about the memory and disk space, how much more memory would you need? The bloxTools environment borrows memory from NIOS, which may be running other services alongside bloxTools. The more memory you allocate to bloxTools, the greater the impact on the other services provided by the hosting member. The disk space is set at 4GB to optimize replication and backups.

We welcome feedback on the bloxTools environment.

+1
0
-1
Re: bloxTools in NIOS 6

We typically find ourselves deploying on 550/1050's, and on the rare occasion 1550's.  So in general we are limited to sharing 256mb of memory with everything else running on bloxTools.

Taking a Perl process minus the Infoblox modules we are looking at around approx 1mb without any other modules loaded or data structures created.  If we simply pull in the Infoblox modules we are looking at an approx 60mb increase in memory before we have actually connected to Infoblox or created any data structures - or even loaded our own code.

If we have multiple processes running under bloxTools for the purpose of backgrounding tasks, and even running many bloxTools snapins, memory is consumed farely easily.

Any SSH access would do, this would greatly improve/ease troubleshooting, having to keep passing code to customers to to get information about something under bloxTools gets a little testing at times, also, it's not always easy since environments are under change control.

Can you direct me to the "Tool Time" blog?

How do you imagine customers will now deploy bloxTools?  Do you imagine that they will host it on existing DNS/DHCP servers, or buy dedicated bloxTools appliances?

I am just trying to understand what the rationale was to move it away from the Grid Master, some of our customers liked this idea, and relied on the replication, and if bloxTools was too much on the Grid Master what affect does it have on a DNS server.

+1
0
-1
Re: bloxTools in NIOS 6

This is an interesting post!

Most of our customers tend to have a more powerful grid master than their member appliances, e.g. grid master may be 1550, but members are only 550, or grid master may be a 2000 with 1050 members. So now if bloxtools is run on a member rather than grid master they will not get the same level of performance. If they have to buy a 2000 or 1550 just to get similar performance then it will start getting expensive. I know we would all like to sell more kit and make more money but I am not sure if a customer will pay that sort of money just for a member to run bloxtools.

Ultimately I guess it depends on the criticality of the app and the amount of budget the customer has. :-)

 

+1
0
-1
Re: bloxTools in NIOS 6

My understanding was that bloxtools was not supposed to be run from the gridmaster in nios 6.

+1
0
-1
Re: bloxTools in NIOS 6

you should take a look at KB 17358. This shows the limitations of bloxtools on a 550/1050.
I have not been able to install the scheduler snapin on bloxtooks on a 550-a even with the memory allocated to 1024mb.
As far as I can see you need a 1552 or greater to run bloxtools.
And if you are going to run it and develop specialized tools on it then you will need a dedicated appliance for production and a separate one for development.
you are correct: it depends on the criticality of the app and the amount of budget the customer has ..... and whether or not bloxtools works at all on the appliance.
The documentation for 6.x.x really needs to change to say bloxtools does not work on a 550/1050.

+1
0
-1
Re: bloxTools in NIOS 6

Thanks, I've already read this article.

Although it states "The 1050-A and 550-A platforms do not have hardware support for virtualization (VMX) and thus applications will be significantly slower running in bloxTools on these platforms in NIOS 6.0 and later." we found it was unusable not slower (even running simple commands like "ls").

I agree the documentation needs to be clearer on this subject.

+1
0
-1