投稿

AMD Ryzen Threadripper 搭載 ワークステーション

イメージ
弊社ではラックマウントサーバや高性能ワークステーションなどを販売しています。その中でも、昨年販売を開始したAMD Ryzen Threadripper搭載のワークステーションがとてもおすすめなので、特徴をご紹介いたします。 AMD Ryzen Theadripperプロセッサ Ryzen ThreadripperプロセッサはAMD社の発売するデスクトップ向けCPUの最上位シリーズです。 デスクトップPCのなかでもハイレベルな処理性能を必要とする3Dゲーム用PCなどに搭載されるCPUですが、本格ワークステーション向けとしても十分な性能と特徴を備えています。  以前よりデスクトップ向けのCPUで性能の高い製品をワークステーション用のCPUとして利用することはありました。デスクトップ向け製品の方がMB等の周辺パーツを含めてサーバ向け製品より安いコストで導入が可能であること、デスクトップ向けのCPUはどちらかといえば動作クロック数重視でシングルスレッド性能が高い製品が多いためワークステーションでの作業用途によっては性能的にも十分であることなどの理由があげられます。  しかし、マルチスレッド性能やメモリエラーに対する信頼性、搭載できるメモリ容量の上限など、それらの要素を必要とする場合にはデスクトップ向けCPUでは十分ではありませんでした。  AMD Ryzen Threadripperプロセッサはデスクトップ向けの製品としての位置付けながらワークステーションに必要な機能もカバーするCPUとなっています。   優れたマルチスレッド/シングルスレッド性能  Ryzen ThreadripperはシングルCPUで最大64コア/128スレッドまでのCPU性能をサポートしています。このレベルのコア/スレッド数を実現するためには今まではサーバ向けCPUによる2CPU以上の大掛かりな構成を必要としていたのですが、Ryzen Treadripperではシンプルにシングル構成で実現可能です。 コア数が多いためにRyzen Threadripperの定格の動作クロックはやや低めです。ただ、いわゆるブースト機能により、少ないコアの稼働であれば動作クロック数をあげることが可能でシングルスレッドでも十分な性能を確保できます。  ECCメモリ対応  Ryzen Threadripperは最大256GBの

最新Intel® Xeon® CPUのメリット

データセンタ等で使われるラックマウントサーバには、サーバ向けのプロセッサであるIntel® Xeon®プロセッサが良く利用されています。 サーバ用のXeonプロセッサは一般的にそれほど馴染みのある製品ではなく、デスクトップ向けのIntel® Core™プロセッサとは何が違うのか、同じXeonでも種類があるがどう違うのか、どの製品が最新のものなのかなどいろいろわかりにくいことが多いと思います。 そこで今回これらの疑問に答えるために、Intel XeonとCoreシリーズプロセッサの違いや、Xeonブランド内での各プロセッサの位置づけについて簡単にまとめてみました。サーバ選びの参考にしてみてください。 XeonとCoreの違い Intel XeonはIntel社製のサーバ向けのプロセッサのブランド名です。 デスクトップ向けのCoreシリーズのプロセッサとの違いはおおよその傾向として次のようになります。 Xeon プロセッサ コア数が多い クロック数よりコア数重視 CPUのキャッシュの容量が大きめ メモリをたくさん搭載できる(最大1TB~4TB) ECCメモリが使える 常時稼働のための信頼性機能搭載 その他、サーバ/ワークステーション向けの機能を搭載 Core プロセッサ コア数は少なめ コア数よりもクロック数重視 メモリはそこそこ搭載できる(最大128GB程度) ECCメモリは使えない 最近はパソコン向けのCoreプロセッサでもゲーミングPC向けなどにサーバ向けに近い性能の製品がリリースされています。しかし、テラバイト容量のメモリのサポートやECCメモリのサポートなどはサーバ向けのXeonに限定されているようです。 Xeonの種類 Xeonには2CPU以上の構成が可能で大容量メモリを搭載可能なハイエンドサーバ向けの高性能製品『Xeon Scalable Processor』と1CPU専用で性能がやや抑えめの普及価格帯の製品『Xeon-E プロセッサ』がラインナップされています。 Xeon Scalable Processor ハイエンド向けの高性能製品 2CPU以上の構成が可能(最大8CPU) コア数が多い(最大28コア56スレッド)。 大容量メモリを搭載可

賢いサーバの選び方

イメージ
サーバが必要だけど、どんなサーバを選べば良いのか? いろいろな機能があるけど、どれが必要なのか? そもそも普通のパソコンをサーバにするのはダメなのか? サーバを選ぶにあたり、いろいろな疑問があると思います。 そこでサーバ選びのポイントとして、サーバの機能や構成についてまとめてみました。サーバの用途に応じて重要と考えられる機能をピックアップし、参考となる構成を紹介しています。 サーバ選びの参考にしてみてください。 サーバとして大切な特徴 多くの場合、サーバは24時間365日常時稼働しつづける必要があります。サーバにはそのための様々な機能が用意されています。ここではとくに重要な特徴としての次の4つのものを上げてみました。 冗長電源 ECCメモリ 最新のサーバ向けCPU BMCによるリモートマネジメント これらの機能はいわゆるデスクトップ向けのパソコンには搭載されていない、サーバ向け製品のみに用意されているものです。 冗長電源 どんなに高性能なサーバでも電源が故障しては動作できません。常時稼働しつづけるためには冗長電源が重要です。冗長電源を用いることにより片方の電源が故障しても、もう片方の電源で動作を継続することができます。故障した電源はサーバの電源を投入したままで交換可能です。電源は将来的なデバイスの拡張に備えて、また障害時に片方の電源だけでも必要な容量をまかなえるようにあらかじめ大きめの容量の電源を選択しておくと安心です。 Tips 電源容量 冗長電源かどうかに限らず、サーバを選定するにあたって電源の容量が充分か確認しておくことが大切です。 アイドル時のサーバの省電力化が進む一方、大容量メモリやメニーコアプロセッサ、GPUやRAIDなどの拡張カードなどによってアクティブ時の電力は大きくなる傾向にあります。すべてのデバイスが最大電力で動作した場合、また将来的にデバイスを追加した場合に容量がギリギリにならないかチェックしておきましょう。また、サーバ用の電源ユニットは入力が100Vか200Vかで最大容量が大きく変わる製品もあるので設置する場所の入力電源(コンセント )が100Vか200Vか確認しておくことも大切です。 ECCメモリ 常時稼働していく上で問題となるのが

SATA12台でのRAID構成可能な1Uサーバ

イメージ
最近のサーバでは1Uサイズでも2.5インチのドライブを10台から12台搭載できます。しかし搭載しているRAIDカードが8ポートまで対応の製品のためにRAIDカードに接続可能なディスクは最大8台までという制限があり、残りのドライブは通常のSATAポート等に接続しなくてはならないという製品がほとんどでした。 EZ1D-Scalable-SATA12  そこでせっかく12台搭載できるのだから12台でRAIDを構成したいというご要望にお応えして こちら( EZ1D-Scalable-SATA12 ) の製品をご用意しました。 サーバに搭載可能な2.5インチドライブ12台全てを利用してRAIDアレイを構成することができます。デュアルソケット対応でアプリケーションの処理性能も充分、12台で構成されたRAIDの性能をフルに発揮することが可能です。 12台でRAIDを構成することにより8台での構成の場合と比較してより柔軟にRAIDを構築することができるようになります。また8台の構成では現実的でなかった特殊なアレイ構成も可能となります。 12台のドライブによる大容量ストレージ 2台のホットスペアを備えたRAID6  用途に応じた複数のRAIDアレイを1つのサーバ上に構築 RAID50やRAID60といった特殊なアレイの構成 ありそうでなかった12台対応RAID搭載1Uサーバ。ぜひご検討ください。 製品の紹介ページ EZ1D-Scalable-SATA12 主な仕様 CPU 対応CPU 第2世代インテル® Xeon® スケーラブル・プロセッサー 搭載CPU数 2 メモリ 最大容量 1.5TB(1536GB) スロット数 24 タイプ ECC対応 2666MHz DDR4 SDRAM ネットワーク デュアルポート 1Gbpsイーサネット デュアルポート 10Gbpsイーサネット RAIDコントローラ SATA12ポート対応 RAIDコントローラ RAID 0,1,5,6,10,50,60対応 キャッシュメモリプロテクションモジュール搭載 ドライブベイ 12 ホットスワップ対応 2.5インチ SATA/SAS ドライブベイ

SuperMicro Update Managerを試してみる

SuperMicro社が提供している有償ツールのSuperMicro Update Manager(SUM)を試してみました。このツールを利用するとIPMIと同じ感覚でBIOS設定の確認や変更、BIOSファームウエアの更新が可能です。 SuperMicro Update Manager SUM紹介ベージ https://www.supermicro.com/solutions/SMS_SUM.cfm Linux起動中にBIOSの設定を確認したくなることありませんか。Windows環境のマシンであればそのようなツールもあるよう気もしますが、Linux上となるとあまり聞かないと思います。以前、Linux上でEFI変数を利用する方法を試してみたのですが、設定らしきものはバイナリデータになっていて詳細不明で、設定の変更はブートデバイスの優先順位くらいしか変更できませんでした。SuperMicro社が提供しているSuperMicro Update Managerを利用すると簡単に(同社のMB限定ですが)OS起動中にBIOSの設定を確認したり変更したりすることが可能になります。 SUMの機能などの詳細な説明は上記のWebページに詳しく紹介されていますのでそちらを参照ください。今回はBIOS周りの機能を試してみました。 SUMではツールを利用して以下のことが可能です。 BIOS設定の取得 現在の設定やデフォルトの設定などをテキストファイルベースで確認できます。 BIOS設定の変更 テキストファイルベースで設定の変更ができます。ただし変更を反映するには再起動が必要です。 BIOSファームウェアのアップデート BIOSをアップデートをそのままの環境で実行できます(DOS環境はいりません)。ただしアップデートを反映するには再起動が必要です。 また対象のサーバにアクセスする方法として二つの方法あります。 リモート(Out-band)でアクセスする。 別のマシンでSUMを実行してネットワーク経由で対象サーバにアクセスする ローカル(In-band)でアクセスする。 対象サーバ上で起動しているOS(Llnux)上でSUMを実行して自分自身にアクセスする。 IPMIと同様に実際にBIOSの設定を取得したり変更したりする

Serfを試してみました。

非集中型のクラスタ管理ツールのSerfを触ってみました。クラスタ管理というと何かいろいろ大変そうなイメージですが、Serfを利用すると簡単にサーバの死活監視や情報の収集が可能になります。 Serfについて Serfの本家サイト: https://www.serfdom.io/ Serf is a decentralized solution for cluster membership, failure detection,and orchestration. Lightweght and highly available. 本家のサイトのトップページに書かれているようにserfは軽量で高可用性の非集中型のクラスタ管理ツールです。 インストールは簡単。  serfの静的バイナリを各サーバにコピーするだけOK。 マスターサーバのような全体を管理しているノードはない 全てのノードで実行されているserfは平等。 ゴシッププロトコルを利用したノード間のメッセージングツール ノード間でお互いに通信して情報を全体に伝播させる。 各ノードで実行されているserf agent が情報のやりとりをする。 クラスタ内のノードの増減についてのイベント クラスタ内のノードの生死についてのイベント ユーザ独自のイベントを通知することも可能 イベントをトリガにして任意の処理(スクリプト)を実行できる。 これによっていろいろ応用が効くようになる。 例えば、クラスタ内のノードの死活監視やノードが追加/停止したときに自動でロードバランサの設定(バランス先)を変更するなどの使い方が考えられます。 また複数のアプリケーションを組み合わせて利用する場合に全体の統制をとるのに利用できます。元々そのような管理の仕組みのないアプリケーションの組み合わせでも全体を統制するような仕組みを構築できます。 インストール 公式サイトに(静的)バイナリで配布されているのでそれをダウンロードしてきて展開し適当なパスにコピーすればOKです。今回は/usr/local/binに置く事にしました。 # wget https://releases.hashicorp.com/serf/0

コンテナ上でのipvsおよびiptablesの利用

イメージ
従来の仮想マシンと比較して軽量な仮想環境としてコンテナが注目されている。コンテナによる仮想環境での特徴としてコンテナで同じカーネルを共有している点があげられる。 また、コンテナで実際のサービスを提供する場合、アプリケーションがほかにカーネルの提供する機能も必要となる。そこで今回はコンテナ環境下でのカーネルの機能の利用について実際に試してみた。 コンテナ上でのカーネルの機能の利用 コンテナではapacheやmysqlといったプロセスはそれぞれの名前空間で実行されている カーネルはすべてのコンテナでホストのカーネルを利用している。 ipvsやiptablesはカーネル側の機能 コンテナではホストのカーネルを共有しそれぞれのコンテナごとに独立した名前空間を作成して、その上でユーザプロセスを実行することによって仮想環境を実現している。 しかし、実際のサービスなどにおいてはhttpサーバやデータベースなどのユーザプロセスだけではなくカーネルの機能も合わせて利用される。例えば、ロードバランスやパケットのフィルタリングを行う場合などはipvsやiptablesといったカーネルの機能が必要になる。 コンテナ上でカーネルの機能を利用する場合、そのカーネルについてはすべてのコンテナで共有されている点において通常とは事情が異なる。 今回はipvsおよびiptablesについて実際にコンテナ上での利用を試してみた。 システム構成 コンテナ構成図 検証としてWebサーバへのアクセスをLVSを利用してロードバランスするシステムをコンテナを利用して構成することを考える(上図) ホストマシン2台からなる構成で、それぞれのホストにipvsを利用してWebコンテナへのロードバランスを実行するLVSコンテナ、 iptablesとapacheを使ってLVSからロードバランスされてきたアクセスを受けるWebコンテナを作成する。 以下の説明ではそれぞれのホスト及びコンテナの構成方法についての詳細は割愛して、それぞれのコンテナ上でのipvsおよびiptablesの動作および設定についてのみ述べる LVSコンテナ LVSコンテナは2つのネットワークインターフェースeth0、eth1を持ちそれぞれが仮想ブリッジを介して仮想イーサネット(veth)によって