Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

楽天のプライベートクラウドを支えるフラッシュストレージ

1,187 views

Published on

楽天市場を中心に多くのサービスを展開する楽天グループ。
サービスの根幹を支えるデータベースシステムでは、異なるフラッシュストレージを適材適所で使い分けています。「フラッシュストレージ=DB高速化」が常識となりつつありますが、楽天がフラッシュストレージを使う狙いは、他にもあるようです。
本セッションでは、サービス要求に応えるべく日々奮闘する楽天のインフラエンジニアが登壇。増加の一途をたどるサービス数、データサイズ、アクセス数、DB数……そんな激動のインフラをどう安定的に稼働させているのか、プライベートクラウドにおけるフラッシュストレージの導入を中心に、その裏側を明かします。
また、種々のストレージを運用した経験から、フラッシュストレージと他のストレージの違いについてもお伝えします。

Published in: Technology
  • Be the first to comment

楽天のプライベートクラウドを支えるフラッシュストレージ

  1. 1. 楽天プライベートクラウドを支える フラッシュストレージ Feb/22/2017 Koichi Takaizumi Server Platform Group, Rakuten, Inc.
  2. 2. 2 Rakuten, Inc. Founded: February 7, 1997 IPO: April 19, 2000 (JASDAQ Stock Exchange) Office: Rakuten Crimson House (Tokyo, Japan) Employees: 12,981 (as of Dec, 2015)
  3. 3. 3
  4. 4. 4
  5. 5. 5  楽天のシステム概要/規模  楽天のストレージの歴史  ALL-Flashのメリット、デメリット  PoCのポイント
  6. 6. 6 Overview 概要/規模
  7. 7. VMs 7 27000+ VMs 2012 2016
  8. 8. Provisioning 8 500+ VMs/month 2016/01 2016/08
  9. 9. Hosts 9 900+ hosts 2015 2016
  10. 10. Storage (Production) 10 0.0 TB 200.0 TB 400.0 TB 600.0 TB 800.0 TB 1000.0 TB 1200.0 TB 1400.0 TB 1600.0 TB 1800.0 TB 2014-04 2014-05 2014-06 2014-07 2014-08 2014-09 2014-10 2014-11 2014-12 2015-01 2015-02 2015-03 2015-04 2015-05 2015-06 2015-07 2015-08 2015-09 2015-10 2015-11 2015-12 2016-01 2016-02 2016-03 2016-04 2016-05 2016-06 2016-07 2016-08 Storage Capacity (Overall Production Env) TTL USED 2014 2016 1600+ TB
  11. 11. 11 All Flash Array 数 2013 2014 2015 1 4 10 2016 12
  12. 12. 12 ストレージカタログ Type IOPS Availability Latency High No-Limit 99.999% 10ms Standard 500 99.999% 20ms Dev/Stg 500 99.99% Best Effort
  13. 13. 13 物理構成とストレージカタログ High All-Flash Standard Hybrid HDD Dev/Stg
  14. 14. 14 カタログ別使用率 60 15 15 10
  15. 15. 15 種類別使用率(論理サイズ) 40 5 55
  16. 16. 16 物理構成とストレージカタログ High All-Flash Standard Hybrid HDD Dev/Stg
  17. 17. 17 History 楽天のストレージの歴史
  18. 18. 18 200x
  19. 19. 19 200X SAN + SPARC • Sun Microsystems SF10k, SF15k, SF25k, v480 • SAN Storage, 15K Disk, 10K Disk • 4 fabric … …
  20. 20. 20 201x
  21. 21. 21 physical virtual
  22. 22. 22 201x Rakuten Infrastructure as a Service
  23. 23. 23 201x~ のRIaaS構成 Fabric Network (10GbE, 8,16G FC) StorageBlade Server 1U Server VMware
  24. 24. 24 用途  Web, DB, Batch, SAP, VDI  Linux, Windows
  25. 25. 25 Pros and Cons ALL-Flashのメリット、デメリット
  26. 26. 26 Performance 0 5000 10000 15000 20000 25000 H社 SSD H社 10000 FC IOPS
  27. 27. 27 IO Performance  New Search i ndex=i dx_ common_ 3y sour cet ype=pur est r g_ moni t or | r egex Name="^ . *$" | r egex host name="^ . *$" | t i mechar t span=1m sum( ops_ r ead) as r ead sum( ops_ wr i t e) as wr i t e Date tim e range  5,280 events (8/28/14 7:30:00.000 PM to 8/28/14 11:30:00.000 PM ) _time read write 8:00 PM Thu Aug 28 2014 9:00 PM 10:00 PM 11:00 PM 100,000 25,000 50,000 75,000 Visualization ✓5,280 events (8/28/14 7:30:00.000 PM to 8/28/14 11:30:00.000 PM ) _time read_ latency write_ latency 8:00 PM Thu Aug 28 2014 9:00 PM 10:00 PM 11:00 PM 2 4 6 _tim e ↕ read_latency ↕ write_latency ↕ 2014-08-28 19:30:00 1.082000 0.556000 2014-08-28 19:31:00 0.821000 0.715000 2014-08-28 19:32:00 0.777000 0.713000 2014-08-28 19:33:00 0.744000 0.584000 Visualization Latency [msec] IOPS
  28. 28. 28 Cost
  29. 29. 29 Tiering
  30. 30. 30 The issue of Auto Tiering • Latency spikes during region moves2014- 05- 24 Read ServiceTim e Write ServiceTim e 00:00 01:00 02:00 03:00 04:00 05:00 06:00 07:00 08:00 09:00 10:00 11:00 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 20:00 21:00 22:00 23:00 0 200 400 600 800 Running Not running • To been addressed. • To reduce the impact , we migrated top-tier VMs from FC to SSD
  31. 31. 31 All Flash  New Search i ndex=i dx_ common_ 3y sour cet ype=pur est r g_ moni t or | r egex Name="^ . *$" | r egex host name="^ . *$" | t i mechar t span=1m sum( ops_ r ead) as r ead sum( ops_ wr i t e) as wr i t e Date tim e range  5,280 events (8/28/14 7:30:00.000 PM to 8/28/14 11:30:00.000 PM ) _time read write 8:00 PM Thu Aug 28 2014 9:00 PM 10:00 PM 11:00 PM 100,000 25,000 50,000 75,000 Visualization ✓5,280 events (8/28/14 7:30:00.000 PM to 8/28/14 11:30:00.000 PM ) _time read_ latency write_ latency 8:00 PM Thu Aug 28 2014 9:00 PM 10:00 PM 11:00 PM 2 4 6 _tim e ↕ read_latency ↕ write_latency ↕ 2014-08-28 19:30:00 1.082000 0.556000 2014-08-28 19:31:00 0.821000 0.715000 2014-08-28 19:32:00 0.777000 0.713000 2014-08-28 19:33:00 0.744000 0.584000 Visualization Latency [msec] IOPS
  32. 32. 32 Migration
  33. 33. 33 FC to FC
  34. 34. 34 Flash to Flash
  35. 35. 35 All Flash Storage のメリット  圧倒的な高IO、低遅延  Tieringストレージと比べてリーズナブルなSSD単価  性能問題からの解放  問い合わせ激減  階層間移動(Tiering)時の影響なし  オンラインアップグレード時の影響低下  マイグレーションの自由  Disk故障の減少 => 運用コストの低下
  36. 36. 36 All Flash導入から3年以上  導入以来、大きな障害はほぼゼロ  SSD壊れにくい, 10件以下  重複排除ストレージについては新たな考慮点も  キャパシティ計画が難しい  パフォーマンスペナルティ
  37. 37. 37 課題 パフォーマンスペナルティ 高負荷になると容量を消費することも サイジング どれくらいリダクションされるのか? 突然のパフォーマンス低下, 既圧縮データ マイグレーションの自由 オペレーションの増加  NANDの供給不足
  38. 38. 38 System使用領域の増減
  39. 39. 39 Point of PoC PoCのポイント
  40. 40. 40 これまでに検証したプロダクト  Violin  Nimbus  StoreVirtual VSA  PureStorage  Nutanix  VSAN  3Par  XtremIO  NimbleStorage  NetApp cDOT  ScaleIO
  41. 41. 41 Requirement 必要な機能は? 必要な性能は? 状態を確認できるか? コスト
  42. 42. 42 選定基準 • Work • 基本機能、望むファンクションが機能するか? • HA • H/W障害、復旧時のインパクトは?復旧までの時間 • Performance • 望むパフォーマンスが出るか? • Visibility • フェイルを通知、検知できるか? • 性能限界点等を見積もれるか?
  43. 43. 43 多角的な観点でのPoC  Yen/GB  Yen/IOPS  消費電力(ランニングコスト)  可用性  SPOF (Single Point of Failure)  制限事項の確認、volume数、サイズ、ホスト数、…  管理性  IOパフォーマンス(IOPS、Latency)  サイジング指標  重複排除 / 圧縮  VAAIサポート
  44. 44. 44 事前検証(PoC)の重要性  カタログスペックとは?  ミックスワークロード vs 4K Read  ロングラン  計画テイクオーバ時の影響  障害テイクオーバ時の影響  圧縮/重複排除有効時のパフォーマンスは安定している か  電力 (ランニングコスト)  PoC と現実の違い
  45. 45. 45 データリダクション  Free GBをチェックする  Used GB = Capacity GB– Free GB  システムが消費するGB、共通使用領域で消費するGB等  圧縮済みのデータ、重複排除済みのデータ
  46. 46. 46 パフォーマンス測定  毎秒測定 IOPS, Latency , iostat  クライアントサイドで測定  想定する IOサイズ、Read/Write率で測定  ioblazer, vdbench  使用率 80% 以上  ロングラン (2日以上)  パフォーマンス測定時はUsed GBの変化もチェック  圧縮/重複排除有効時のパフォーマンス
  47. 47. 47 HA,障害検証  IO負荷かけ続けた状態  毎秒測定 IOPS, Latency  shutdown, takeover , 計画停止  交換可能モジュールを物理的に外す(ベンダーの許可)  SSD, HDD  FC, iSCSI ケーブル  電源ボタン、ケーブル  SASケーブル  …
  48. 48. 48 H/A Hot-swap IO Wait [sec] priority expected actual result priority expected actual result Controller 1 Yes Yes 1 60 sec 60sec Shelf I/O Module 1 Yes Yes 1 60 sec 3 sec decrease performance 75% SSD 1 Yes Yes 1 0 sec 0 sec decrease performance 50% NVRAM 1 Yes Yes 1 0 sec Under 5sec Power Supplies 1 Yes Yes 1 0 sec 0 sec iSCSI Cable 1 Yes Yes 1 60 sec 60 sec SAS Cable 1 Yes Yes 1 60 sec 0 – 16 sec IB Cable 1 Yes Yes 1 0 sec 6 sec Fans 1 Yes Yes 1 0 sec (60 sec) Priority 1:Must 2:Nice to have 3:Don’t care
  49. 49. 49 Error Trap / Healthy Visibility Mail/SNMP Trap/Logging GUI/CLI Visibility priority expected actual result priority expected actual result Controller 1 Yes Yes 1 Yes Yes Shelf I/O Module 1 Yes Yes 1 Yes Yes SSD 1 Yes Yes 1 Yes Yes NVRAM 1 Yes Yes 1 Yes Yes Power Supplies 1 Yes Yes 1 Yes Yes iSCSI Cable 1 Yes Yes 1 Yes Yes SAS Cable 1 Yes Yes 1 Yes Yes IB Cable 1 Yes Yes 1 Yes Yes Fans 1 Yes non- removable 1 Yes Yes Priority 1:Must 2:Nice to have 3:Don’t care
  50. 50. 50 例)コントローラ障害時の性能劣化 ○ 最大70msecのレイテンシが10秒間発生
  51. 51. 51 例)コントローラ障害時の性能劣化 ☓ 約5分間IOPSが10,000->700に低下
  52. 52. 52 ロングラン
  53. 53. 53 5 minutes
  54. 54. 54 48hours
  55. 55. 55 重複排除
  56. 56. 56 例)重複排除機能による性能劣化 ○ 重複排除OFF時、安定した性能
  57. 57. 57 例)重複排除機能による性能劣化 × 重複排除ON時、IOPS大幅低下。不安定な性能
  58. 58. 58 Feature 期待
  59. 59. 59 あったらいいな 障害時のサービス復旧時間 1秒以下
  60. 60. 60 Wrap up まとめ
  61. 61. 61 まとめ 今では Flash ありき 電力消費量 == ランニングコスト 各ベンダー H/W に大きな違いはないが… データリダクションは容量見積が難しい PoCは必須 パフォーマンス = CPU + (GB) 新興ベンダー 老舗ベンダー
  62. 62. 62 さいごに
  63. 63. 63
  64. 64. 64 ご清聴ありがとうございました

×