Retire services once Server is retired

Shashikant Yada
Tera Guru

Hi All,

Need suggestion or help 🙂

For example: Discovery has created one Linux Server "abc" and multiple services are created "JBoss, ESX, Network Adapter, dvSwitched, SQL, etc.".

Currently abc server is retired, so according to me it should retire all the other services right?

Also how should I report to get all the services running under one Server (Windows or Linux)? and check which all services are retired and which all not?

Thank you for your help in advance 🙂

 

1 ACCEPTED SOLUTION

DaveHertel
Kilo Sage
Kilo Sage

Hi -  If you know server 'abc' is truly retired (i.e. not being used, doesn't exist, etc.) then any APP CI's and related CI's should be removed.  I don't think the App CI's will 'automatically' be removed from CMDB just because the server status is changed (to something like 'retired').   Unless you have business rules or some other automation that is intentionally handling this clean up.    Same thing for Service and other relationships to the now unused server.  The relationships to Services may indeed still be there until you intervene to adjust based on the changing conditions in your IT environment.   

Now, deleting a CI is different... the relationships to app CI's, running processes, etc. should get cascaded-deleted.  BUT deleting CI's isn't a best practice.  Generally, changing the status (to something like 'retired') is a better holistic approach to configuration management practices.

Of course automation thru business rules, policies, etc. that may be customized on your instance, changes all these answers -- i.e. your mileage may vary based on how your environment is setup.

Hope this helps?

 

View solution in original post

4 REPLIES 4

DaveHertel
Kilo Sage
Kilo Sage

Hi -  If you know server 'abc' is truly retired (i.e. not being used, doesn't exist, etc.) then any APP CI's and related CI's should be removed.  I don't think the App CI's will 'automatically' be removed from CMDB just because the server status is changed (to something like 'retired').   Unless you have business rules or some other automation that is intentionally handling this clean up.    Same thing for Service and other relationships to the now unused server.  The relationships to Services may indeed still be there until you intervene to adjust based on the changing conditions in your IT environment.   

Now, deleting a CI is different... the relationships to app CI's, running processes, etc. should get cascaded-deleted.  BUT deleting CI's isn't a best practice.  Generally, changing the status (to something like 'retired') is a better holistic approach to configuration management practices.

Of course automation thru business rules, policies, etc. that may be customized on your instance, changes all these answers -- i.e. your mileage may vary based on how your environment is setup.

Hope this helps?

 

Dave is correct here you should really look at what types you are talking about and think very carefully about whether to retire or delete. My suggestion is only delete what is causing data explosion issues (e.g. if it's a switch you can look at deleting some of the next hops and such). For a server infrastructure I wouldn't delete anything in the cmdb_ci_appl table as they are more then likely referenced by other things. The tcp/ip and process table can be looked at for deletion as generally those aren't referenced by anything else.

Either way make sure you do a per table overview of each of your related tables to what you want to retire and determine based upon your company policy what would be acceptable to remove versus just marking operational status as retired (your CI pickers on your ITSM process forms should all have a filter not to show operational status of retired so they won't show up anymore there). Thanks.

Thank you Dave and Robert that helps.

How should we report? to get all the services under one server.

Well this entirely depends on what you decide to retire as some use cmdb_ci_rel and others use reference to link them. Either way you should have a business rule which when it goes to retire state you either automatically lookup and retire/delete or you create a task for approval to the CMDB team and then on approval you do that work. Either works really ( I like the approval one if you don't have solid processes for tracking your status changes).