w3ll1ngt commented on code in PR #13741: URL: https://github.com/apache/ignite/pull/13741#discussion_r4446411362
########## docs/_docs/server-node-file-system-layout.adoc: ########## @@ -0,0 +1,230 @@ +// Licensed to the Apache Software Foundation (ASF) under one or more +// contributor license agreements. See the NOTICE file distributed with +// this work for additional information regarding copyright ownership. +// The ASF licenses this file to You under the Apache License, Version 2.0 +// (the "License"); you may not use this file except in compliance with +// the License. You may obtain a copy of the License at +// +// https://www.apache.org/licenses/LICENSE-2.0 +// +// Unless required by applicable law or agreed to in writing, software +// distributed under the License is distributed on an "AS IS" BASIS, +// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. +// See the License for the specific language governing permissions and +// limitations under the License. + += Server Node File System Layout + +Plan disk space separately for persistent data, WAL, retained WAL segments, snapshots, logs, and JVM diagnostics. +If these files share a file system, growth in one directory can exhaust the space needed by the others. +A failed write to Ignite data, WAL, or metadata can cause the node to stop. +A full file system can also prevent the node from restarting. + +These recommendations apply to production server nodes. +For nodes without native persistence, the recommendations for the work directory, logs, and JVM diagnostics still apply. + +Not every role can be isolated: CDC and the root of an incremental snapshot chain are hard-linked to WAL archive segments and therefore have to live on the archive file system. +Isolate the remaining roles. + +== Separate Capacity and I/O + +Use separate file systems or volumes with independently provisioned capacity to contain disk-space exhaustion. +Different directories on the same file system share free space and do not provide this isolation. +A separate file system is a capacity boundary only: it does not by itself reduce I/O contention, which requires a separate device or independently provisioned storage throughput. + +Separate the roles for a second reason: they compete for the same device queue. +Data files receive checkpoint batches, the active WAL receives the writes of the commit path, and the archive, CDC, and snapshots add their own sequential streams. +When these streams share a device, a spike in one of them delays the others, and the delay appears while the load is at its highest. + +Separate partitions on one physical device isolate capacity but not I/O: they still share the device queue, the controller, and the failure risk. +For I/O isolation, place data files and the active WAL on different physical devices or independently provisioned storage. +Separate the archive as well where possible, so that archiving and retained segments do not compete with the active WAL. +Include the underlying shared storage pools in capacity and throughput planning. + +== Recommended Placement + +[cols="1,1,3", options="header"] +|=== +|Files |Configuration |Placement and reason + +|Data and indexes +|`DataStorageConfiguration.storagePath`; all additional configured data and index paths +|Use dedicated, durable data file systems. Keep logs, diagnostic files, and retained backups off these file systems to protect checkpoint writes and recovery from unrelated growth. + +|Active WAL +|`DataStorageConfiguration.walPath` +|Use a dedicated file system, separate from data and preferably from the WAL archive. This protects the space needed for WAL writes and keeps the files of the two roles apart. To reduce the competition between checkpoint page writes and WAL writes, place the active WAL on a separate device or on independently provisioned storage throughput. + +|WAL archive +|`DataStorageConfiguration.walArchivePath` +|Use a file system with capacity planned for retained WAL, CDC, and incremental snapshots when enabled. This file system also hosts these two consumers, because both link to archived segments. +Provision throughput as well as capacity: if the archiver cannot keep up with the peak WAL rate, the working segments run out and the write waits. +Include the extra load of WAL compaction and of the consumers that read the archive, such as CDC and incremental snapshots. +Keep the archive separate from data and active WAL where possible. Review Comment: added guidance to check checkpoint duration, page-write time, and fsync time. It is also now linked to metrics system. inho it is not neccessary to add some numbers in vacuum. It is better to ocunt on workload based numbers rather then hardware thresholds metrics - in one day ssd will be working at different rates -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
