存储效率，数据减少，性能与压缩

  • 2017年5月18日
  • 2回答
  • 2612的浏览量
C
排名
Userlevel 3
徽章 + 14
  • 切 Nutanix员工
  • Nutanix员工
  • 8回答说
Nutanix技术营销工程师Andy Daniel最近写了一篇简短的文章，概述了包括压缩在内的存储效率特性。在您的环境(Nutanix或其他)中，分享您为不同的工作负载所做的工作。

--
为了优化存储容量和提高应用性能，Acropolis分布式存储Fabric使用了重复数据删除、压缩和擦除编码等数据效率技术。他们是聪明的和适应性的，在大多数情况下，需要很少或不需要微调。事实上，在新的运输集群上，默认情况下，在与冷数据分类一起启用了两个级别的后处理压缩。因为它们完全是由软件驱动的，这也意味着现有客户可以通过升级AOS来利用新功能和增强功能。

DSF提供内联压缩和后处理压缩，以最大化容量。很多时候，客户错误地将压缩与性能下降联系在一起，但对于Nutanix来说，情况并非如此。事实上，从AOS 5.0开始，所有随机写操作在被写入OpLog(写缓存)之前都被内联压缩，无论选择的配置是什么。压缩所增加的Oplog空间利用率改善了对持续随机写的突发处理，并允许在更长的时间内吸收持续随机写。

大的顺序读写也可以从压缩中获得性能上的好处，因此很少有不适合使用inline压缩(压缩延迟= 0)的工作负载。它甚至被推荐用于一级工作负载，如Oracle、Microsoft SQL Server和Exchange。内联压缩还可以提高容量层(Extent Store)内的性能，同时最大化总可用存储容量。

有了潜在的显著性能改进和显著增加集群有效存储容量的能力，现在没有理由不启用容器压缩!
    \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
    徽章 ＋２
    我被这句话弄糊涂了

    大的顺序读写也可以从压缩中获得性能上的好处，所以很少有不适合使用inline压缩(压缩延迟= 0)的工作负载。它甚至被推荐用于一级工作负载，如Oracle、Microsoft SQL Server和Exchange。Inline压缩还可以提高容量层(Extent Store)内的性能，同时最大化总可用存储容量。”

    这一说法似乎与……直接矛盾

    “压缩最佳实践”——https://portal.nutanix.com/#/page/docs/details?targetId=Web_Console_Guide-Prism_v4_7:sto_compression_c.html——

    压缩数据的计算成本较高，而解压缩数据的计算成本较低。从这个事实可以得出这样的结论:数据只写入一次就经常读取的工作负载(比如用户数据存储)最适合压缩。这类工作负载的例子包括文件服务器、归档和备份。
    因为压缩的数据不能进一步压缩，所以这样做只会消耗系统资源而没有任何好处。无论是主要由本地压缩数据(如JPEG或MPEG)组成的用户数据，还是有本地压缩的系统(如SQL Server或Oracle数据库)中的数据，都不应该存储在压缩容器中。”

    虽然这是模棱两可的，因为您可能会或可能不会在SQL上使用压缩，但似乎有一个好处——压缩数据在计算上是昂贵的。我最近一直在研究这个话题，因为我们有一个SQL server运行在单个主机上，这是一个庞大的VM占用了整个节点(896GB RAM/20 vCPU)，我们注意到这个主机与CVM争用。这主要是我们抛出硬件的一个应用问题，但自从我们把它移出使用SSD SAN的HPE环境后，我们开始注意到，自从它移到Nutanix后，磁盘上的延迟越来越大。Nutanix建议我们启用inline压缩，这是在6个月前完成的，但现在我们有一个CVM，它的CPU峰值很高，经常运行在100%。我们计划给CVM更多的vcpu，但我想知道如果我们禁用inline compression，我们会看到更少的争用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或Native SQL 2016，谁对哪种压缩更有意见?就个人而言，我喜欢在VM / SQL2016级别启用它，因为如果您在您的NUTANIX环境中只有一个数据池，就像我们做的那样，您必须为所有访问该存储的系统启用它?

    回复


    Baidu