储存效率，降低数据和压缩性能

C
秩
UserLevel 3
徽章 +14
  • chheda Nutanix员工
  • Nutanix员工
  • 8个答复
Nutanix技术营销工程师安迪·丹尼尔（Andy Daniel）最近写了一段简短的段落，以概述包括压缩在内的存储效率功能。分享您在环境中（Nutanix或其他方式）中为不同的工作负载所做的事情。

- -
为了优化存储容量并加速应用程序性能，Acrocolis分布式存储面料使用数据效率技术，例如重复数据删除，压缩和擦除编码。它们具有智能和适应性，在大多数情况下，几乎不需要或根本不需要微调。实际上，默认情况下，在新运输群集上默认情况下，启用了两个级别的后处理压缩。因为它们完全是软件驱动的，所以这也意味着现有客户可以通过升级AO来利用新功能和增强功能。

DSF同时提供内联和后处理压缩，以最大程度地提高容量。很多时候，客户错误地将压缩与性能降低相关联，但Nutanix并非如此。实际上，从AOS 5.0开始，无论选择哪种配置，所有随机写入都会在写入OPLOG（写缓存）之前被压缩。由于压缩的结果，增加的OPLOG空间利用可改善持续随机写入的爆发处理，并可以在更长的时间内吸收持续的随机写入。

大型和顺序的读取和写入也可以看到压缩的性能好处，因此很少有工作负载在线压缩（压缩延迟= 0）是不合适的。甚至建议用于诸如Oracle，Microsoft SQL Server和Exchange之类的层工作负载。内联压缩还提高了容量层（范围存储）内部的性能，同时最大化可用的可用存储容量。

凭借潜在的急剧性能提高以及显着提高集群有效存储容量的能力，您没有理由今天不应该对容器进行压缩！
    \n
    \n--
    \nTo optimize storage capacity and accelerate application performance, the Acropolis Distributed Storage Fabric uses data efficiency techniques such as deduplication, compression, and erasure coding. They are intelligent & adaptive, and in most cases, require little or no fine-tuning. In fact, two levels of post-process compression are enabled in conjunction with cold data classification by default on new shipping clusters. Because they\u2019re entirely software driven, it also means existing customers can take advantage of new capabilities and enhancements by upgrading AOS.
    \n
    \nDSF provides both inline and post-process compression to maximize capacity. Many times, customers incorrectly associate compression with reduced performance, but this isn\u2019t the case with Nutanix. In fact, as of AOS 5.0, all random writes are compressed inline before being written to OpLog (write cache), no matter the chosen configuration. Increased Oplog space utilization as the result of compression improves burst handling for sustained random writes and allows absorption of sustained random writes for a longer duration.
    \n
    \nLarge and sequential reads and writes also see a performance benefit from compression, so there are very few workloads where inline compression (compression delay = 0) isn\u2019t appropriate. It\u2019s even recommended for Tier-1 workloads such as Oracle, Microsoft SQL Server and Exchange. Inline compression additionally improves performance within the capacity tier (Extent Store) while maximizing total available storage capacity.
    \n
    \nWith potentially dramatic performance improvements and the ability to significantly increase your cluster\u2019s effective storage capacity, there\u2019s no reason you shouldn\u2019t enable compression on your containers today!","quoteUsername":"chheda","translations":{"Common":{"like":"Like","unlike":"Unlike"},"Forum":{"Quote":"Quote","Share":"Share"}}}">

    2个答复

    NSEGALLE
    徽章 +2
    我对这个陈述感到困惑 -

    "Large and sequential reads and writes also see a performance benefit from compression, so there are very few workloads where inline compression (compression delay = 0) isn’t appropriate. It’s even recommended for Tier-1 workloads such as Oracle, Microsoft SQL Server and Exchange. Inline compression additionally improves performance within the capacity tier (Extent Store) while maximizing total available storage capacity."

    该声明似乎是与 -

    “压缩最佳实践” --- https：//portal.nutanix.com/#/page/docs/details?targetId=web_console_guide-guide-prism_v4_7:sto_compression_c.html---

    “压缩数据在计算上是昂贵的，而解压缩数据则较少。从这个事实中，可以遵循一个工作负载，而在数据写入的地方并经常读取，例如用户数据存储，最适合压缩。此类工作负载的示例是文件服务器，是文件服务器，存档和备份。
    由于压缩数据无法进一步压缩，因此尝试这样做会消耗系统资源而无益。在具有本机压缩（例如SQL Server或Oracle数据库）的系统中，主要包括主要压缩数据（例如JPEG或MPEG）的用户数据都不应存储在压缩容器上。”

    尽管这是模棱两可的，因为您可能会或可能不会在SQL上使用压缩，但是似乎有一个取回 - 压缩数据在计算上是昂贵的。我最近一直在研究这个主题，因为我们有一个在单个主机上运行的SQL Server，该主机是一个怪物VM占用整个节点（896GB RAM/20 VCPU），我们注意到与此主机上的争论有关CVM。这主要是我们将硬件扔给的应用程序问题，但是由于我们已经将其从使用SSD SAN的HPE环境中移开，因此我们开始注意到磁盘上越来越高的延迟，因为它已移至NUTANIX，。Nutanix建议我们启用大约6个月前进行的内联压缩，但是现在我们有一个CVM尖刺CPU，通常以100％的速度运行。我们计划为CVM提供更多的VCPU，但是我想知道我们是否要禁用内联压缩，我们会在此主机上看到CVM的争论较少吗？想法？
    \r\n
    \r\n\"Large and sequential reads and writes also see a performance benefit from compression, so there are very few workloads where inline compression (compression delay = 0) isn\u2019t appropriate. It\u2019s even recommended for Tier-1 workloads such as Oracle, Microsoft SQL Server and Exchange. Inline compression additionally improves performance within the capacity tier (Extent Store) while maximizing total available storage capacity.\"<\/i>
    \r\n
    \r\nThis statement seems to be a direct contradiction to - -
    \r\n
    \r\n\"Compression Best Practices\" - - https:\/\/portal.nutanix.com\/#\/page\/docs\/details?targetId=Web_Console_Guide-Prism_v4_7:sto_compression_c.html - -
    \r\n
    \r\n\"Compressing data is computationally expensive, while decompressing data is less so. From this fact it follows that workloads where data is written once and read frequently, such as user data storage, are most suitable for compression. Examples of such workloads are file servers, archiving, and backup.<\/i>
    \r\nBecause compressed data cannot be compressed further, attempting to do so consumes system resources for no benefit. Neither user data that comprises mainly natively compressed data (such as JPEG or MPEG) nor data in a system that has native compression (such as SQL Server or Oracle databases) should be stored on a compressed container.\"<\/i>
    \r\n
    \r\nAlthough it's ambiguous because you may or may not be utilizing compression on SQL, but it seems there is one take away - compressing data is computationally expensive. I have been researching this topic lately because we have a SQL server that is running on a single host, which is a monster VM taking up an entire node (896GB RAM\/20 vCPU), and we're noticing contention on this host with the CVM. This is mostly an application problem that we're throwing hardware at, but since we've moved it off of out HPE environment which utilized SSD SAN, we're starting to notice higher and higher latency on the disks since it's been moved to Nutanix. Nutanix recommended we enable inline compression, which was done about 6 months ago, but now we have a CVM who is spiking CPU and often running at 100%. We plan to give the CVM even more vCPUs, but I'm wondering if we were to disable inline compression we'd see less contention of the CVM on this host? Thoughts?","quoteUsername":"nsegalle","translations":{"Common":{"like":"Like","unlike":"Unlike"},"Forum":{"Quote":"Quote","Share":"Share"}}}">
    银翼杀手
    徽章
    有人在运行大型SQL数据仓库，Nutanix或本地SQL 2016时是否对哪种压缩有意见？就我个人而言，我喜欢在VM / SQL2016级别上启用它，因为如果您像我们一样在Nutanix环境中只有一个数据池，则必须为所有访问该存储的系统启用它吗？

    回复


    Learn more about our cookies.<\/a>","cookiepolicy.button":"Accept cookies","cookiepolicy.button.deny":"Deny all","cookiepolicy.link":"Cookie settings","cookiepolicy.modal.title":"Cookie settings","cookiepolicy.modal.content":"We use 3 different kinds of cookies. You can choose which cookies you want to accept. We need basic cookies to make this site work, therefore these are the minimum you can select. Learn more about our cookies.<\/a>","cookiepolicy.modal.level1":"Basic
    Functional","cookiepolicy.modal.level2":"Normal
    Functional + analytics","cookiepolicy.modal.level3":"Complete
    Functional + analytics + social media + embedded videos"}}}">
    Baidu