ITOM - Trying to understand how the storage servers are connected to linux servers

[dikshithara]

Hello All,

Greetings!

This is my first question on the community. 

I am new to ITOM, I have 6 months of experince in ITOM.

I have never been so stuck in Servicenow before 😄

I am trying to find out a solution for - if any storage server goes down, is there a way we can determine the impact on other CI's hosted on that storage and applications that were running on this server.

We first ran a proper discovery on that storage, we have 4 errors in the discovery though, where sensors are absent.

There were no proper relationship built between the servers and the application.

We are trying to see if their is any relationship between the storage and the application, so that we can then go ahead and build a service map which will help us to get the view of the impact on the servers connected to this storage.

I am trying to understand if any relationship even exists between the storage and the application servers?

I would be really grateful for your responses, that will help me, because I have been trying to solve this since very long.

Thank you.

[Pratiksha]

The use case solution will be service mapping. When you built a top down map it will help you say if one of the ci goes down what would be the impact. 

[dikshithara]

Yes, but I have a list of few servers, which are supposed to be under the storage server.

I am not sure how to go ahead and build the service map, as the relationship between this storage server and the linux server( from the lists that we have) is not built. We discovered both storage server as well as the linux server.

[Pratiksha]

Their are two things : 

1) Where database services runs on servers

2) you will have database servers

Which one you are working right now? 

[BasantChauhan]

 If your Horizontal Discovery is working correctly for both your storage devices and your servers, it will create the fundamental infrastructure relationships.

Discovery Errors : If Discovery can't fully inspect the storage, it won't be able to establish relationships. First try to diagnose the errors that could be related to any one or multiple things: 

• Insufficient Credentials: The MID Server might not have the correct or elevated credentials (e.g., administrator, storage-specific user, SMI-S credentials) to access the storage device.
• Network Connectivity/Firewall: Firewalls (network, host-based, or storage array internal) might be blocking the necessary ports (e.g., SMI-S, SNMP, SSH for command-line access) for the MID Server to collect data.
• Missing Software/Protocols: The storage device might not have the necessary agents, protocols (like SMI-S, CIM, specific vendor APIs), or configurations enabled for Discovery to extract data.
• Discovery Patterns/Probes: The out-of-the-box (OOB) patterns/probes for that specific storage vendor/model might not be working correctly, or you might need custom patterns for non-standard configurations.

Solution : Step 1 :- Review Discovery Logs, Verify credentials, Check ports and protocols.

Step 2 : Test Individual Probes/Patterns:- If you can identify the failing sensor, you can often test the underlying probe or pattern separately from a full discovery to isolate the issue. 

Step 3: Establish Server-to-Storage Relationships via Discovery

Step 4: Establish Server-to-Application Relationships

Installed Software (Horizontal Discovery): Discovery finds software installed on servers and gives you the basic "runs on" relationship.

Utilize Service Mapping: This is where you connect the dots to actual application services and their dependencies.

Identify Critical Business Services: Start with one or two critical business applications that you know rely on the problematic storage.

Create Application Service Maps: Use Service Mapping to discover and map these application services. This will draw the connections from the application's entry point down to the servers, databases, and critically, the storage they use.

Troubleshoot Service Mapping Patterns:Service Mapping also uses patterns and write custom patterns if all connections are not drawn automatically.

Step 5: Review CMDB Health 

• CMDB CI Classifications: Ensure your storage CIs are classified correctly (cmdb_ci_storage_server, cmdb_ci_storage_volume, cmdb_ci_storage_disk, etc.).
• Relationship Types: Understand the standard relationship types used by Discovery (e.g., Uses::Used by, Runs on::Runs, Contains::Contained by). Ensure they are being created.