We have an ITOM/OpsB customer who has a potentially large volume Vertica need. If, as an example, we (Micro Focus) thinks they might need say 8 nodes with 32 cpus and 256gb memory each eventually over time, how should we recommend they start for initial lower volume? Would Vertica experts recommend them deploying, say, 3 or 4 nodes first each with the large cpu count and memory and add nodes later, or should they start with 8 nodes (presumably ESX VMs) of smaller footprint each and add cpu and memory to them later as needed?
Question
Advice on how to grow a potentially large Vertica cluster?
+2
+2Hi dgrumann,
Vertica clusters are sized on the physical size of the database (10tsd meter view).
To do this (find the # of cluster nodes) there are two ways
- get the physical DB size from the raw data volume and the compression factor for OpsB
- have experience with this customer (e.g. a system for 10 tsd network interfaces needs 4 nodes, the new system has to monitor 30 tsd network interfaces)
To my understanding the raw data volume would result from the OpsB sizing sheet. From my work with ITOM I am on the impression that there is no experience on the compression factor (would 100 TB raw result in 50 TB or 20 TB compressed tables on disk).
If the system "has a potentially large volume Vertica need" I would rather start with a small cluster (4 nodes) and see how things develop over time. I needed, you add nodes to the cluster later.
Certainly you need to discuss this approach with your customer.
Good luck
Dieter
+2Yes Dieter I know you have helped us some to attempt to size systems, and we appreciate it. This question is not about the DB size at all. We are presuming the sizing calculator is correctly predicting the eventual size of the DB. The question is more about how to start with a small cluster that will then grow to become very large at a later point. If the cluster will eventually need 8 256MB memory nodes, then I think you are suggesting that it would be better to start with 4 256MB nodes instead of, say, 8 64GB nodes. In other words it is better for Vertica to evolve over time by adding more nodes of the same capacity, as opposed to increasing the capacity of all the existing nodes over time. The obvious problem with adding nodes is the extensive rebalancing that would need to occur every time a new node is added. If, instead, we would start with 8 smaller nodes and then, say, increment the cpu count and memory on each of them via individual reboots over time, that would seem to avoid more rebalancing.
+2Hi, in the V world scale-up (adding HW to a node later) is not recommended.
V is MPP and clusters grow by adding more nodes of the same sort (scale-out).
If we are assuming our raw data sizing is correct then the question is on the planning horizon of the HW purchase.
So if the planning horizon is 2 years then you would do a sizing for that time interval.
V rebalance is an online operation and causes no downtime.
+2OK Dieter thank you, however in most cases, ITOM Service Assurance products like NOM and OpsB are being implemented on ESX VMs when on-prem, not separate HW. The ESX servers are presumably already in place and of fixed size, however the customer does not wish to immediately allocate 8 VMs each with 256GB of memory when their initial workload and DB size will be small. Also note for customers using AWS, Vertica is also virtual for example the customer needs to specify the node count of "Standard_D8s_v3" Vertica nodes. I will presume your advice stays the same, and we will recommend customers NOT start with smaller VMs and change then, instead start with fewer VMs of larger size each.
+2Hi Doug,
the planning should start with getting clear on the requirements. Then translate this to technology.
Is the customer needing more compute, more storage, both, on what timeline?
In a classic MPP model (like V enterprise) each part of the database is getting the same treatment (is considered a "hot piece of info").
If ITOM applications are doing analytics on a "hot subset" (eg the last two months where you keep detail data) while you consider the growing amount of aggregates "cold history" then there will be no additional need for compute but for storage only.
If your installation uses VMs and SAN storage there should be no issues, simply let the DB grow.
On a different topic: why being afraid of a supposedly "expensive resegmentation in 2 years" if the project has not even started and the are not any data on the real impact?
If you are wanting to separate compute and storage you should have a look at Vertica EON.
Dieter
+2Thanks for the follow-up Dieter. We know the requirements; they get spit out of our calculator. The question is about ramping from smaller initial ingestion (think in terms or MB per second), to larger eventual ingestion, without replacing the nodes hosting the DB. Since it is a data lake, we can expect queries to use all history, though not often. The customer is not willing to initially deploy eight nodes each with 256MB of memory to handle what they know is a smaller ingestion rate. It sounds like best practice is to allocate fewer larger nodes at first.
Sign up
Already have an account? Login
Welcome to the Rocket Forum!
Please log in or register:
Employee Login | Registration Member Login | RegistrationEnter your E-mail address. We'll send you an e-mail with instructions to reset your password.
77 4th Avenue
Waltham, MA 02451 USA
