This diagram provides a conceptual overview of the relationship between a deployment server and its set of deployment clients and server classes: By creating a server class, you are telling the deployment server that a specific set of clients should receive configuration updates in the form of a specific set of apps. You use server classes to map a group of deployment clients to one or more deployment apps. For example, you can group all Windows clients into one server class and all Linux clients into another server class. For more information on Splunk Enterprise apps in general, see "What are apps and add-ons?" in the Admin manual.Ī server class is a group of deployment clients that share one or more defined characteristics. Note: The term "app" has a somewhat different meaning in the context of the deployment server from its meaning in the general Splunk Enterprise context. The deployment app can be an existing Splunk Enterprise app or one developed solely to group some content for deployment purposes. Over time, an app can be updated with new content and then redeployed to its designated clients. A deployment app might consist of just a single configuration file, or it can consist of many files. Each deployment client belongs to one or more server classes.Ī deployment app is a set of content (including configuration files) maintained on the deployment server and deployed as a unit to clients of a server class. Deployment clients can be universal forwarders, heavy forwarders, indexers, or search heads. A deployment server cannot be a client of itself.Ī deployment client is a Splunk instance remotely configured by a deployment server. Any full Splunk Enterprise instance - even one indexing data locally - can act as a deployment server. Deployment apps can be full-fledged apps, such as those available on Splunkbase, or they can be just simple groups of configurations.Ī deployment server is a Splunk Enterprise instance that acts as a centralized configuration manager for any number of other instances, called "deployment clients". After which, the heavy forwarder will send the data to Splunk Cloud or Splunk Enterprise via port 9997.You use a deployment server to distribute content and configurations (collectively called deployment apps) to deployment clients, grouped into server classes. If you decide that a heavy forwarder makes sense for your architecture based on the points above, you will send the data from the SAP system to the heavy forwarder using port 8088. For Splunk Enterprise, port 8088 needs to be open, and for Splunk Cloud, port 443 needs to be open for outbound web traffic (i.e., data flowing from SAP to Splunk). Required network ports cannot be opened by the network team. The customer already uses a heavy forwarder in their existing environment architecture IT Security team expresses concerns with allowing the SAP system to communicate directly outside of the internal firewall Below is a list of considerations that can help customers determine whether a heavy forwarder should be included in their PowerConnect architecture: However, some customers may opt to use a Splunk heavy forwarder maintained in the same network as their SAP system, and then forward the data from the heavy forwarder to either their Splunk Enterprise or Splunk Cloud environment. This is the preferred method for integrating the Splunk and SAP systems because it requires the least number of connections to send the data (reducing potential failure points) and reduces customer infrastructure costs. The PowerConnect application can connect directly to both Splunk Enterprise and Splunk Cloud environments from the SAP system if the appropriate networks ports are open.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |