smartstor

[nkarthik]

Hello Community,

 

We have a very big smartstor DB on our production environment. We have done smartstor cleanups but that has n't helped much. We are working on fine-tuning agents to send only required metrics.

Due to huge smartstor, collectors are performing slowly which in turn causing entire cluster to slow down. Customers need the complete smartstor so there are some suggestions to work on this.

 

1) Create a query only cluster - Move the entire smartstor DB from live production cluster to query only cluster. The query only cluster can be used for historical query purposes. Drop smartstor DB in production and start from scratch. After a while, merge historical query only cluster and live production cluster. I know we can create query only cluster, move the data, drop the DB in production. But Is it possible to merge the older historical query cluster to live production environment if required in future?

 

2) As per CA's recommendations, only 10 collectors allowed per cluster. Can we add up more collectors if capacity requirements exceeds? I think this is not officially supported. Am I correct? What will be performance impact to APM if we add more than 10 collectors?

 

3) There is an option to set the metric clamp for agent, lets say for 1500. Is there way to specify what metrics can be allowed in this 1500? I mean is there a way to specify allow SQL, JSP in those 1500. I don't think we have an option to restrict metrics/allow metrics by individual metrics level. Is that right?

 

Thanks,

Karthik

[Anon Anon]

Hi Karthik,

 

1) Create a query only cluster - Move the entire smartstor DB from live production cluster to query only cluster. The query only cluster can be used for historical query purposes. Drop smartstor DB in production and start from scratch. After a while, merge historical query only cluster and live production cluster. I know we can create query only cluster, move the data, drop the DB in production. But Is it possible to merge the older historical query cluster to live production environment if required in future?

 

<Kulbir> You can possibly do that however I don't see any advantage of doing it, it's better to keep historical cluster separate from live and eventually retire it. Even if you combine both you will still have the limit of 10 collectors per MOM.

 

2) As per CA's recommendations, only 10 collectors allowed per cluster. Can we add up more collectors if capacity requirements exceeds? I think this is not officially supported. Am I correct? What will be performance impact to APM if we add more than 10 collectors?

<Kulbir> Yes it's not officially supported\tested\certified configuration. You can setup a separate cluster and use CDV to query combined data.

 

3) There is an option to set the metric clamp for agent, lets say for 1500. Is there way to specify what metrics can be allowed in this 1500? I mean is there a way to specify allow SQL, JSP in those 1500. I don't think we have an option to restrict metrics/allow metrics by individual metrics level. Is that right?

<Kulbir>That's correct understanding.

 

Regards,

Kulbir.

[nkarthik]

Hi Kulbir,

 

1) If you say merge is possible, do you refer about merge option provided using smartstor tools to merge two smartstor directories? Does that work here?

 

2)Thanks for the clarification that it's not officially supported. But can we added more collectors(one or two) to the cluster? If we add it, what is the performance impact? For your reference, we have already 10 agent collectors and 2 MTP collectors in our cluster. Can we add one or two to this cluster?

 

Another question is when smarstor reperiodization is happening, it deletes the aged out data after the data satisfied tier 3 configuration. Is there a way to move the deleted/purged data to another file system/storage? Do we have such an option?

 

Thanks,

Karthik

[Anon Anon]

Hi Karthik,

See inline

1) If you say merge is possible, do you refer about merge option provided using smartstor tools to merge two smartstor directories? Does that work here?

 

<Kulbir> By merge I actually implied bringing EM's with older smartstor data back into the production cluster, possibly SmartStorTools merge will also work but I don't really get the logic behind doing all this extra work. You are moving out data in first place because it's huge and probably causing performance issues, then why would you want to merge it back and basically amplify the original problem ? My recommendation would be to keep the historical cluster totally separate for reporting purposes and eventually once data is aged just retire it. Meanwhile when you start afresh with prod cluster make sure to have tighter controls on incoming data so you don't run into similar situation again.

 

2)Thanks for the clarification that it's not officially supported. But can we added more collectors(one or two) to the cluster? If we add it, what is the performance impact? For your reference, we have already 10 agent collectors and 2 MTP collectors in our cluster. Can we add one or two to this cluster?

 

<Kulbir> Since it's not supported that would imply we don't really don't do any additional testing to observe what the impact from extra collectors would be, but as a general rule of thumb one or more bad performing collectors, affect entire cluster performance, more you have greater the chances of instability.  To avoid any supportability\performance issues I would recommend setting up a parallel cluster and use CDV to look at all clusters holistically.

 

Another question is when smarstor reperiodization is happening, it deletes the aged out data after the data satisfied tier 3 configuration. Is there a way to move the deleted/purged data to another file system/storage? Do we have such an option?

 

<Kulbir> No, if you really don't want data to be deleted just archive it externally to a different directory.

Regards,

Kulbir.

[nkarthik]

Hi Kulbir,

 

Thanks for the answers

 

Actually customer is not happy to create a query only cluster but they just want to move old data to some external file system during this peak period and once peak period is settled, they wanted to merge it back to original platform.

 

Thanks,.

Karthik