Service level management means meeting the performance, scale, workflow, user base, and data services requirements according to pre-defined service levels. In consolidated environments servicing a multitude of factory devices, operational workflows, and users, service level requirements for various segments of the environments are varied. They may range from mission-critical environments to mid-tier operations and even low-tier environments used for reporting, QA, and development.

Service level management ensures that the right set of resources are available to service the needs of these diverse environments which can dynamically scale up and down with shifting priorities. Service level management planning encompasses a range of components and operational details to ensure high-performing and efficient manufacturing edge operations that meet the demand for the application service levels.

More emphasis can be given to top-tier applications, factories, and processes to ensure the highest service levels compared to mid-tier and low-tier environments, which are assigned a lesser degree of importance.

For the Dell Validated Design for Manufacturing Edge, the following service level management aspects are considered:

• Data ingest sources, frequencies, and user base
• Size and number of ISV application instances
• Type of the databases for model and persistence store
• Data retention period
• Compute, storage, and memory allocations for virtual machines and edge gateways
• Number of virtual machines and their clone copies
• Database backup, recovery, HA, and DR required
• Number of configured objects, visualizations, and their data rates for reads and writes
• Real-time and historical analytics operations and affected data sets

Manufacturing operations use a variety of sensors, PLCs, robots, cameras, and other devices that ingest telemetry and video streams. Data collection frequency varies based on the operation, priority, and analytics.

The type and value of information also differs based on the manufacturing operations they affect. The number of connected users to such systems varies based on the amount of automation or complexity of the operation. Telemetry data might be from large sources with a smaller data size, whereas image or video data may come from just a few cameras with very high data density based on the number of frames and resolution of the captured images.

Also, textual or string data processing may be less resource-intensive compared to machine vision data processing. Systems need to be designed to handle these data sets according to their relative priorities, performance, and throughput requirements.

The sizing of ISV application instances depends on the number of factories, connected users, and data sets that they need to manage. Based on the scale and sizing requirements, multiple instances can be configured on the supported infrastructure by this DVD, and it is important to evaluate data service requirements for various instances to ensure ease of management, desired availability, and user experience.

Using a large number of small instances may pose operational challenges and result in lower overall efficiency. But small instances also allow for smaller copy sizes, ease of backup and restore due to finer granularity, ease of migration for changes in the scale as the application demands change, all resulting in better overall system management.

Alternatively, keeping a small number of large instances may make adding new systems easier due to the extra capacities these instances have. But large instances make it difficult to manage due to higher complexity and the number of underlying systems supported by them. It is important to plan the deployment with current and future growth in mind and to consider the overall complexity of the OT and IT systems.

ISV application instances use different models to store the data locally, and may also offer store and forward to other layers and persistence stores. They can also be configured to have persistence providers for long-term data retention and independent data management.

Here are some considerations for better design of database providers for higher scale and performance:

• Separate data and log devices and use multiple data and log devices for better concurrency of read and write operations. Typically, using two to four data and log devices allows for proper queuing for I/O operations with lower latency and higher throughput.
• Databases allow for the creation of file groups for proper administration, data allocation, and placement using role-based access controls. Such physical separation also allows the restoring of specific files/groups in the event of some logical or physical corruptions without affecting other objects.
• The size of the data files and their storage extent growth rates can be appropriately configured to minimize the number of storage requests and have disk space pre-allocated for database writes.
• Windows and Linux operating systems allow user specification of allocation units when creating partitions and file systems when formatting the disks. A 1 MB allocation unit is recommended instead of using smaller allocation units. Modern disks have larger sector sizes and using 1 MB allocation unit aligns well with those larger disk sizes.
• Choose appropriate database log retention policies, monitor the log file usage, and backup and truncate those logs periodically for smooth database operations and to avoid database operations being halted if logs get full.
• Set up the right set of indexes to speed up query operations. Too many indexes will result in overhead, so plan ahead and set up indexes on critical tables. Indexes can also be created once the tables are populated, but this results in additional overhead for ongoing operations while indexes are configured.

Manufacturing edge operations ingest and process lots of data. Most of the analytics operations leverage the most recently generated real-time data for quick decision making regarding current manufacturing operations. But historical data has its own merit, as it can help identify trends and help with predictive maintenance and forecasting using past performance. The performance of queries decreases and the overhead of data management increases with the size of the data set. So, it is important to consider data retention and employ a strategy to either purge or archive historical data to be used when needed for certain use cases.

Older data can also be migrated to systems with higher compression and duplication for storage efficiency and effective access whenever needed. Some databases also have linked external tables which allow maintaining the locality of the data set without affecting the ongoing operations.

VxRail is a hyperconverged infrastructure appliance that leverages VMware virtualization technologies for virtualizing compute, storage, and networking using its multinode, clustered configuration. It offers high flexibility to create virtual machines with configurations that meet the grow-as-you-grow model for future scale demand. Configure the virtual machines based on the minimum requirements for ISV application environments to accommodate use workloads and the capacity and performance needs for the applications and databases supporting them.

Although several applications can run on a single virtual machine, it is beneficial to create virtual machines based on their workload profile and data segmentation. This helps with appropriate data services configurations on those VMs for better management. Proper choice of virtual machine configuration also helps with effective use of the performance monitoring tools at the VxRail, VMware, or guest OS level. Use of multiple hard disks and para-virtualized SCSI controllers assigned to them helps with higher performance of the system and provides flexibility for ISV applications.

VMware offers effective VM-level cloning to allow rapid provisioning of additional VMs. This is used to maintain a common set of templates to create additional environments based on common standard practices. These templates can also be exported as OVF templates to configure environments for other factories and plants. Periodic clone copies can also help to quickly recover the environment in the case of some logical corruption or accidental failure. When planning for virtual machines for the manufacturing edge, consider service levels and data services needs for the VM and configure the appropriate number of virtual machines to manage specific applications.

Databases should be periodically backed up to have copies of the data in the event of failures. The backup strategy should also consider configuration files, SQL, and Java Scripts use for management and monitoring, containers, and visualizations used for developing user dashboards. Analytics tools and processes must be backed up to effectively use the data ingest without interruptions. VxRail offers HA with underlying cluster, multipathing, and redundancy, as well as vMotion for better load balancing and availability across those clusters. Such HA and backup configurations should be periodically tested, especially for mission-critical environments, to ensure availability in the event of real failures.

An effective disaster recovery strategy should involve consideration for an environment in a third-party failure domain to allow quick failover in case the primary environment goes offline. This can be done by leveraging a secondary system or alternate VxRail environment to copy primary data sets, backups, and configurations for quick application restart.

VxRail provides VM-level clones which are application-agnostic for the quick restart of all applications on that VM, and leveraging periodic clones will help resume the operations quickly; as opposed to performing recovery operations on individual ISV applications, databases, file systems, and configuration files on that system.

The number of configured connections, external data tables, devices and tags, and visualizations is accountable for the system load and performance profile at a given point in time. The data rates vary according to their size and frequency, and they put stress on the system in the event of spikes. For example, when the users are first connecting, running some analytics operations, or configuring new objects, the system needs to handle the additional level of workloads. Some of them result in heavy writes or some heavy reads, or a combination of both, which stresses the entire system as various components compete for the available resources.

Real-time and historical data sets are leveraged by analytics applications for creating operations dashboards and running analysis for overall equipment efficiency, predictive maintenance, proactive maintenance, and forecasting. Result sets can also be shared with other parts of the business such as supply chain management, ERP systems, inventory management, and so on. Such collaborative systems require flexible, seamless access to the data from diverse data sources and data providers. They also leverage on-premise and cloud services to create tiered analytics services that can learn from each other and add capabilities along the way. Service levels for such analytics operations require scaling up and down, seamless integrations with different sources and APIs, and identifying and correcting issues with minimal disruptions to overall workflow. These applications also benefit from having access to the most recent data set and periodic refresh of their data sets to influence the overall system performance with smart decisions.