Clyso Enterprise Storage (CES)

website·Indexed 34 days ago

https://docs.clyso.com/

Documentation for Clyso Enterprise Storage (CES), including installation guides via cephadm, migration paths from SUSE Enterprise Storage and other Cephadm-managed clusters, and release notes for versions 1.0.0, 24.11.0, and 25.03.2. Features include the Ceph Copilot CLI tool, the CLYSO Monitoring Module for Prometheus metrics, and a comprehensive Ceph Knowledge Base for troubleshooting and best practices.

Tokens
55.1K
Snippets
281
Records
475
Agent score
58%

What's inside Clyso Enterprise Storage

  1. Overview of S3 Object Lock modes

    S3 Object Lock makes objects immutable to prevent unauthorized deletion or encryption (e.g., by ransomware). There are two primary modes:

    1. Governance Mode: Objects can be deleted by users who possess the s3:BypassGovernanceRetention permission.
    2. Compliance Mode: Objects cannot be deleted by any user until the specified retention date has passed. The retention period can be extended, but it cannot be reduced, and the mode cannot be changed to Governance mode once set.
  2. Overview of Chorus Object Storage Replication

    Chorus is data replication software designed for Object Storage systems, supporting both S3 and OpenStack Swift APIs. It allows users to replicate data from a 'main' storage endpoint to one or more 'follower' storage endpoints. Key capabilities include zero-downtime migrations, live synchronized backups for disaster recovery, and data integrity verification via diff checks.
  3. Implement a time synchronization architecture for Ceph

    To ensure stability and scalability, use a hierarchical NTP stratum approach. The recommended architecture distributes time as follows:

    1. External NTP Sources (Stratum 1): Public servers like pool.ntp.org or time.nist.gov.
    2. Ceph Monitor (MON) Nodes (Stratum 2/3): Sync to multiple external sources, peer with each other for consistency, and act as NTP servers for the rest of the cluster.
    3. OSD/MDS/RGW Nodes (Stratum 3/4): Sync directly from the MON nodes. These nodes do not need to peer with each other.
  4. Key features of the CES 18 series

    The CES 18 series includes the following primary technical features:

    • Ceph Reef Base: Built on Reef 18.2.8 to incorporate the latest stability fixes.
    • CLYSO Monitoring Module: Includes a dedicated CLYSO manager module used for diagnostics, health checks, recovery tooling, and metrics push.
  5. Understand CES 24.11 Release Series specifications and support status

    The CES 24.11 release series is built on Ceph Quincy 17.2.7. It is currently an archived release and is recommended only for existing Quincy-based deployments. Security updates are no longer provided for this release line, and it reaches End of Life 12 months after the CES 18 release.
  6. Understand Chorus S3 API replication compatibility

    Chorus replicates S3 API operations between storages. It is designed to work with any S3-compatible storage and has been tested with Clyso Enterprise Storage (CES), Ceph RGW, AWS S3, and Minio.

    Critical Constraint: Only S3 to S3 replication is supported.

  7. Understand CES 25.03 and CES 18 versioning

    CES 25.03 has been renamed to CES 18 to align with the upstream Ceph release versioning. Both names refer to the same 'Reef' release line. While the original 25.03 numbering was based on the release date (Year 2025, Month 03), the product is based on Ceph Reef 18.2.4. Users should refer to the CES 18 documentation for current information.
  8. Analyze Docker disk usage and container mappings

    Use the following commands to get a high-level overview of Docker disk usage or to map running containers to their specific overlay directories on the host filesystem.
    # Get brief overview of docker space usage
    docker system df
    
    # Script to map running containers to their overlay directories
    if [ -f rpt ]; then rm rpt; fi; echo "CONTAINER_ID NAME OVERLAY_DIR" >> rpt; for d in $(docker ps | grep -v CONTAINER | awk '{print $1}'); do name=$(docker inspect $d | jq -r '.[] | .Name'); overlay=$(docker inspect $d | jq -r '.[] | .GraphDriver.Data.MergedDir'); echo $d $name $overlay >> rpt; done; cat rpt | sed 's|/ceph|ceph|' | sed 's|/merged||' | column -t
  9. Best practices for Ceph time synchronization

    Time synchronization is a fundamental requirement for Ceph cluster stability. Follow these guidelines to prevent quorum issues and election storms:

    • Use Chrony instead of ntpd.
    • Configure Monitor (MON) nodes to peer with each other.
    • Prevent sudden time jumps.
    • Maintain clock skew below 50ms (target < 10ms).
    • Use a local NTP server whenever possible.
    • Monitor synchronization continuously and address warnings immediately.
  10. Understand Ceph RGW Bucket Index Sharding

    Bucket indexes track all objects in an S3/Swift bucket using RADOS OMAP. To prevent a single RADOS object from becoming a bottleneck, the index is sharded across multiple objects using a hash function.

    Key Constraints:

    • Performance Threshold: A single shard should generally not exceed 100,000 entries. Exceeding this may trigger Ceph warnings and degrade performance.
    • Listing Trade-off: Listing operations must query every shard and merge-sort results. Increasing the shard count improves write parallelism but can slow down listing operations if the shard count is high relative to the object count.
    • Maximum Shards: The shard count ceiling is 65,521.
  11. Understand the importance of time synchronization in Ceph

    Ceph uses the Paxos consensus algorithm and requires closely synchronized clocks across all nodes, especially Monitor (MON) nodes. Clock skew can prevent quorum formation, cause election storms, and lead to cluster instability. By default, Ceph warns when clock skew exceeds 50ms (mon_clock_drift_allowed = 0.05).

    Symptoms of clock skew include:

    • HEALTH_WARN clock skew detected messages
    • Monitors stuck in probing, electing, or synchronizing states
    • Monitors failing to join quorum
    • Client authentication failures