はてなキーワード: zabbixとは
仮想システムを構築するにあたり、CIFS しか使えない NAS をバックアップ用に選定してきた SI 屋さんが居たので、CIFS と iSCSI のどちらが早いのか、試してみました。
テストに使う NAS は QNAP の Turbo NAS TS110
http://www.tekwind.co.jp/products/entry_6719.php
です。もう6年以上愛用して、カビが生えてもおかしく無い程に古いし, Marvell 800Mhz という低スペックな Qnap NASです。 100Mbps 時代のモノです。
昨年、HDDがお亡くなりになったので、3Tb の HDD に交換しました。ファームウェアはこんなに古い機械でも、QNAP シリーズの最新バージョンが利用できます。
iSCSI は、今あまり見なくなりましたが SCSI ケーブル規格や、SASケーブル接続のハードディスクを、一般的なIPネットワークで規格で仮想化したものです。
マウントするホストシステム側は iSCSI initiator, ディスクストレージの機能を提供する側を iSCSI Target と呼びます。
ホストから「マウントするしない」はイニシエータ側のソフトウェア的な操作で行います。これは便利な機能で、ディスクの故障などで、一時的に物理的に取り外さなければいけない場合でも、ホストからの操作だけで実際のケーブル結線の脱着を行う必要がないので、今時での SAS の外付けディスクドライブの様に、ホストもシャットダウンして電源を切り、結線を外して修理、交換する、という必要がないので、ディスクデバイスの修理をホストの電源を止めないで実施できると言う、実に便利な事ができます。
という事で、仮想環境では実に使いやすいストレージデバイスなのです。
マウントするホスト側から見ると単純に SCSI/SAS のハードディスクに過ぎません。iSCSI のストレージをマウントしてからは、通常の増設ディスクの様にフォーマットして、ホスト側で使う一般的な XFS, ext4, NTFS などのフォーマットでフォーマットする必要があります。
Linux の iSCSI ターゲット側からは、内部にターゲットとして使う「巨大なファイル」が、どん! とあるだけです。この巨大ファイルを、イニシエータ側に仮想ディスクイメージとして提供しています。当然シンプルな仮想イメージなので、ファイルそのものをバックアップコピーすれば、ストレージのイメージそのもののバックアップができます。
※ qnap NAS の場合、iSCSI イメージは、 /share/HDx_DATA/.@iscsi.img の下にドンと作られるようです。
[Solved]How to mount iSCSI file?
https://forum.qnap.com/viewtopic.php?f=180&t=25322
[/share/HDA_DATA/.@iscsi.img] # pwd
[/share/HDA_DATA/.@iscsi.img] #
[/share/HDA_DATA/.@iscsi.img] # ls -l
-rw------- 1 admin administ 6442450944 Nov 12 2017 iSCSI-2015ace1-5a078d66.000
-rw------- 1 admin administ 1073741824 Jun 24 09:52 iSCSI-lun4-5d0de534.000
-rw------- 1 admin administ 107374182400 Nov 4 2015 iSCSI-nss01-56399e1a.000
-rw------- 1 admin administ 5368709120 Nov 11 2017 iSCSI-nss2015-5a06cf6d.000
-rw------- 1 admin administ 21474836480 Jun 22 17:11 iSCSI-test-56b3ce90.000
-rw------- 1 admin administ 5368709120 Jun 22 17:11 iSCSI-test-56b3ce90.001
[/share/HDA_DATA/.@iscsi.img] #
※ とても重要
CIFS/NFS のファイル共有NAS と違い、iSCSI でマウントして一つのターゲットを制御できるのは、一つのホスト、一つのイニシエータだけです。複数のホストからイニシエータでマウントする(できちゃいます)と、ファイルの排他制御は行われないので、ファイルシステム自体の不整合が起こります。
つまりファイル共有という目的には向いていない、という事です。あくまでも iSCSI ターゲットはネットワーク上の仮想ディスクです。
もっとも、一つのホストからマウントしてファイルを保存して、いったんオフラインにして、ターゲットを別なホストからマウントする、という事はできます。また、ターゲットは一つの iSCSI デバイスで複数作れるので、1台の iSCSI 装置に複数のターゲットを実装して、複数のホストから別々のターゲットイメージをマウントする事は問題ありません。
極端な話、ホストのハイパーバイザーは USB メモリやSANブートさせて、後はマウントした iSCSI の仮想イメージ上で、仮想マシンを動かす、HDDレスなハイパーバイザー運用もできます。
物理的な転送速度は、ネットワークの速度とディスクデバイスの性能に依存します。当然 10Gb base のネットワークカード、HUB、高規格なケーブルを使えば、論理的な性能は 10Gbps です。大抵は NAS の性能がそこまで出ないのですけどね。ヨドバシカメラあたりで売っている 4,000 円程度の 1G HUB でも、そこそこの性能が出てしまいます。
距離は、IPがつながればどこでもなので、ホストコンピュータとメインのストレージを自社のサーバールームに置き、イニシエータを動かし、バックアップ用の iSCSI ターゲットをデータセンターに置く、なんてこともできます。
【送料無料】QNAP TS-431P2(ホワイト) NAS 4ベイモデル クアッドコア CPU / LAN 2ポート搭載 (TS431P2)
価格:56,145円
感想(0件)
iSCSI の耳慣れない言葉に LUN (論理ユニット番号 : Logical Unit Number)というのがあります。
昔の SCSI は、 SCSI バスアダプタに7番のIDを振り、残りの 0 ~ 6 のディスクや CD, Tape などに ID を振り分ける物理的な3ビットのディップスイッチやジャンパ端子が付いていました。これが SCSI アドレスです。
これが実に難物でした。特に、複数の SCSI バスアダプタカードをデュプレクス設定する場合、割り込み番号も別々にするので、手が滑ってジャンパピンを飛ばして床を這いまわって探したり、難解なディップスイッチを前に数日悩んだものです。
つまり一つのSCSIバスには 0~7の合計8台(うち大抵7番はSCSI バスカード)の物理ユニットデバイスがつながって別々に見えたという仕組みだったわけです。
ところが SCSI バスを使った Raid コントローラが出てくると、ディスクの鈴なりが、一つの物理デバイスに見えてしまうわけです。これを「論理的な仮想番号」に分割して、システムからは、単一の鈴なり Raid ディスクを複数の論理番号に分割したわけですね。
これが LUN というヤツです。
iSCSI 機器のターゲットも、内部のソフトウェア的に複数の論理デバイスに分割して、複数のホストコンピュータから複数の物理デバイスのように見せかけるわけです。
別々な LUN は一つ、あるいは複数の iSCSI 機器によって、複数のホストに別々のディスクデバイスとして見せかけるンです。
https://en.wikipedia.org/wiki/Logical_unit_number
Qnap NAS の場合、iSCSI ターゲットはウィザード形式で簡単に作成できます。EXT4 ファイルシステム上で、オンラインでも簡単にサイズの拡大ができるので、 Windows の Storage Server のように NTFS の VHD 形式ではないので、そこそこ性能が出ますが、いかんせん古さと遅さは否めません。
Qnap NAS の iSCSI ターゲットの設定は、偉そうな Linux 系サイトに書いてある程、面倒なことはありません。ストレージマネージャから iSCSI タブにあるウィザードに従って iSCSI ターゲット名に任意の名前を付けると IQN にその文字列が追加されるだけです。わざわざ vi エディタに「正確に」綴りを間違えずに設定する必要もありません。ここでは Chap 認証は付けませんでした。
仮想化時代の NAS 選び - やっぱり iSCSI は早い。_a0056607_16405779.jpg
機械は古いのですが、逆に言うと、「古くて遅い」ため、サーバーとNASとの接続プロトコルの性能差が、如実に現れる事になります。
QNAP TVS-951X 10GBASE-T/NBASE-Tポート内蔵
Windows10 の Microsoft 製 iSCSI イニシエータは「コントロールパネル」>「システムとセキュリティ」>「管理ツール」の中にあるので、ここで、設定済の iSCSI 「ターゲットを」 「検索」して選んで「接続」します。Chap 認証を付けておいた場合はターゲットで設定したパスワードが必要でしょう。
仮想化時代の NAS 選び - やっぱり iSCSI は早い。_a0056607_16412132.jpg
新規に作成して、接続した後は、フォーマットされていないため、ディスクマネージャからフォーマットして使います。ちなみに、フォーマットして利用した iSCSI ターゲットの仮想ディスクは、他のマシンでマウントすることもできます。つまりHDDを取り外して、他のPCに繋げる事と同じことですね。
PR
ちなみに opeSUSE で使うにはこんな感じになりました。
open SUSE Leap 15.1 で iSCSI NASを使ってハマった
https://islandcnt.exblog.jp/239328437/
一番イラつくのは、巨大なファイルの転送でしょう。という事で 3G 程ある SUSE Linux のインストール用DVDの ISO ファイルを CIFS でコピーしてみます。
仮想化時代の NAS 選び - やっぱり iSCSI は早い。_a0056607_16414334.jpg
3分11秒かかりました。1Gビットネットワークで 12~3% 程度の帯域を使って通信しています。明らかに古いNAS の性能が足を引っ張っているようです。
スループットは 150Mbps 程度で全体の最大15%程度でしょうか。
仮想化時代の NAS 選び - やっぱり iSCSI は早い。_a0056607_16415832.jpg
仮想化時代の NAS 選び - やっぱり iSCSI は早い。_a0056607_16422170.jpg
初速は出るのですが、その後は、ボロイ TS-110 の性能がモロに出ます。それでも 20 MB/s から 25 MB/s 程度は出ています。
仮想化時代の NAS 選び - やっぱり iSCSI は早い。_a0056607_16423835.jpg
2分25秒でした。 大体20%程度のスループットです。
--
数字に弱い私の脳みそですが、 iSCSI は CIFS より 1.5倍くらい早い、という事が言えます。
Zabbix で QNAP TS-110 の I/O を見てみると、前半の CIFS アクセスより後半の iSCSI アクセスの山が高い事がよくわかります。
仮想化時代の NAS 選び - やっぱり iSCSI は早い。_a0056607_16425860.jpg
CIFS を使ったリモートディスクのマウントは、他のPCからもアクセスができる、というメリットがありますが、iSCSI は単一のホストからのアクセスしかできません。<--- これ重要.... -- もっとも、ターゲットストレージを複数作って複数のサーバーから異なるデータ領域にアクセスはできますが -- バックアップ用途や、サーバーの増設ストレージとして考えれば、良い選択であると言えます。
もっとも、iSCSI デバイスそのものは、ターゲット単位で別々なホストから接続できます。しかし同じターゲットで別々のホストからイニシエータから繋ぐと、とても笑いごとにならない事態になるので、普通やりません。
ハイパーバイザー同士で一つのターゲットを共有してライブマイグレーションはしたことはあります。
こうした性能のわずかな違いが、仮想化システムのハイエンドな領域で違いとなって出てきます。なお Qnap でも openiSCSI でも Windows Storage Server でも取った領域そのままのサイズのでかいファイルが作成されるようです。
国産 NAS の「ハイエンド」と称する「LANxxxx」などのモデルでは Windows Storage Server を使って NTFS フォーマットしています。Windows Storage Server は見た目 Windows サーバーそのものなのですが、ところどころちゃんとデチューンされているようで、SOHO向けが限度です。
こういった国産 NAS メーカーの製品カタログでは、「ハイエンド」は Windows Storage Server を搭載して、低価格のNASは Unix 系のシステムで「低価格」を謳っていますが、そもそも、上位モデルは、CPUやメモリの性能が高いものが使われています。性能が違うのは当たり前なのですが、あまり性能が出ないだろうと思います。
Windows Storage Server じゃなくて、ちゃんとした Windows Server と CAL 買えよな、という事なのですね。
このあたりは独自OSを NAS としてチューニングした Qnap や Synology, asuster などの iSCSI 機能付きの NAS を中規模ネットワークのミドルレンジの NAS として利用したほうが良いと思います。
仮想環境でのネットワークアタッチストレージ(NAS)は、本回線(構内LAN)とは切り離し、ストレージ専用のネットワークとして独立して運用させるのが基本です。サーバーとNAS間で凄まじい通信が発生します。サーバーNICが2ポート以上のものが推奨されます。
iSCSI はあくまでもネットワーク上のストレージのみの機能を提供するものであり、ファイル共有の手段ではない、という事です。
NAS をCIFSで使うと NAS が持つ独自のアクセス権限を設定しなければなりません。セキュリティも当然 NAS 独自の機能で設定します。
iSCSI はあくまでも「外付け SCSI デバイス」のネットワーク版なので、マウントする側のOSそのもののファイルシステム、セキュリティ機能、アクセス制限がホスト側の機能をそのまま利用できます。セキュリティ的には、マウントする際のパスワード制限しかないので、独自のストレージネットワーク内に配置すべきで、ユーザが使う構内ネットワークに配置すべきではありません。
4年間、製造業向けのインフラエンジニアとして働いていたが、今日の出来事で辞めることを決意した。
【はじめに】
情報工学系の大学を卒業し、中規模ぐらいのSlerに入社、サーバ・ネットワーク関連を扱う部署に配属
配属された理由として、研究がサーバ仮想化やクラウド関係の内容だったこともあり「サーバ関連なら詳しいだろう」という理由
主に大手製造業の研究開発で使用されるサーバを導入・保守を続けてきた
サーバ運搬するにも100kg近いサーバを4~5人で運ぶのは当たり前だったし、サーバのキッティング作業、LANケーブルや電源ケーブルの配線もあるから大変&大変
また、保守作業も加わるから、サーバを引き出してHDDを交換したりマザーボードも交換する
デスクワークは4~5割ぐらいの印象
サーバ基盤環境作るためにサーバの構成やラッキング図、ネットワーク設計図などの設計書も作った
はじめはサーバもネットワークも設計書の作成は手伝い的な立ち位置だったけど、2年目からはサーバ機器のエンジニアになっていった
【やめようと思った理由1:失敗は許せない、効率よりも完璧主義者になれ】
今までもやめようと思ったことはあったけど、この経験できっぱりとやめることが決断できた
↓
↓
上司「チェックはどうしているんだ」
↓
俺「自分が部品交換してOSで取ったログを確認して問題なければ、常駐している社員にも確認させています」
↓
上司「それまでの流れは?」
↓
俺「事前に作成してあるマニュアル通りに沿って部品交換作業をしています また、ソフトウェアの扱い方を事前に調べておいて対応しています」
↓
上司「それじゃあダメだ データセンターへ移動するときの常駐メンバーへの連絡~部品交換完了まで一からチェックシートを作って細かくチェックをつけながら作業しろ」
上司「保守作業でミスしたらお前に保守の仕事やらせないからな」
↓
俺「...」
呆れたよ
ただでさえ、導入しているサーバ数が1000台以上あって限られた人しかデータセンター内で働くこともできない職場だってのに
ほぼ毎日のようにZabbixアラートがバンバン飛んでまた生産性のない作業を増やすのか!?って思ったわ
それに毎回同じ障害内容じゃないのに、チェックシートを作るとなると事前準備だけで時間食うし、短期間で解決しなきゃいけない障害もあるのに無謀すぎるだろ
自分も保守作業でミスをしてはいけないっていったら、そりゃあミスしないのが一番に決まっている
常駐メンバーへの連絡→チェック
データセンター内に入るときに不要な電子機器の持ち込みはないか確認→チェック
:
なんかもう保守作業自体やりたくなくなったし、会社の中で上司の命令に忠実で完璧主義者にならないと仕事できないのかなあって思った
以前にも同じように、
誰かが1つミスをする
↓
↓
って流れを4年間で何度も何度も見てきているから、効率を求めるよりも完全に正確性だけしか考えていない上司やプロパーばかりだった
そのせいもあり、社内で使う技術がレガシーだったりExcel至上主義が当たり前になっていた
2ch創業者のひろゆきの配信で「ITの仕事は他の業界の人員を削減するためにある」って言っていたけど、IT企業なのに自社で時間のコストばかり増えて効率化とは程遠い存在になってしまっていた
そんな繰り返しの環境にいたら自分がおかしくなってしまいそうって思い、退職を決意した
GAFAでも個人情報流出を何度もやっているミスを犯しているけど、それでも業績は確実右肩で伸びているし利用しない人がいなくなっていないどころか増えているんだよな
それは、1つのミスをやったとしてもそれを有り余るだけの魅力的なコンテンツやプロダクトを利用してる人が多いから発展し続けているんだよ
ニコニコ動画だと、プレミアム会員数の減少や現存ユーザ数も少なくなっているなどで悪いニュースしか流れない感じで、コメントが流れなくなったり通信障害やメンテナンスの長期化など様々な問題を起こしてきたのも事実だ
しかし、それがニコ動が衰退した大きな理由ではなく、「某動画サイトのほうが機能もコンテンツも充実している」「某配信サイトでは無料なのに、ニコ動は有料だ」的な理由が大きく占めるからミスして終わりではないんだよ
一方俺の会社は、ミスを防ぐだけの取り組みをしているがプロダクトや技術力などの魅力があるわけではないから詰んでいるけどねw
というかそんな取り組みしても、自分もそうだが社員は何かしら問題起こすから意味がなくなっているけども
まず、驚いたこととしてサーバにアテンションランプがつきまくりで、HDDやメモリが壊れていることも普通な感じで放置されていた
そんな環境で100台以上ものサーバを運用しているから、さらに驚いた
なんでそうしているのか、現地で働く人に話を聞いたら「キッティングするのが仕事で、それ以外は契約外」の一点張りだった
別にそんな話をしたことでその人はビクッて驚いた様子もなく堂々としていた
日本の今の会社で働いていると、「この期間までにキッティングを完了しろ」「翌日までに保守対応しろ」と期間内で解決するためのプレッシャーに押しつぶされそうになったり、担当外の会社に導入しているサーバ保守や設計、キッティングも手伝ったりってことでジョブが確立されていない
「日本の常識は世界の非常識」とよく言われる通り、このまま10~20年以上いたら上司みたいに外の世界をよく知らない人物になってしまうかもしれない
この経験で、このまま今の会社の文化に洗脳されてもしリストラか倒産されたとしてこの先エンジニアで生きていけるのか不安になった
【やめようと思った理由3:インフラよりもWeb開発が好きだと気づいた】
まあ、ベンチャーで神のようなエンジニアとは程遠いけど、自分でWebサイトを作ったり機械学習を使って統計取ってみたりQiitaに勉強会の感想や学んだ技術について書くことが多かった
インフラの知識を使ってサーバ構築したりするけど、自分の発想力でサイトを作るプログラミングが楽しく、昼頃から深夜の5時くらいまでプライベートで開発していたことが何度もあった
今の仕事よりもweb系開発企業に属したほうが全然マシなんじゃないかと思った
周りの社員からもベンチャー向きかベンチャーで働いたほうが良くね?って言われることがあったから、周りの推薦もあって自分も転職しようと決意できた
【これから】
まぁタイトルの通り。
AWS といえば各種便利機能を提供してる大手クラウドサービスで、
CloudWatch も監視機能として有名だし利用している人も多いかもしれない。
ウチのサービスも当初はCloudWatchを利用していた。
便利だしコストも安いし管理サーバの冗長化とか考えなくていいからね。
でもな、ウチの会社さ、突然バックアップにデータセンター/Azure/GCPにもサービス置こうぜと言い出した。
で、調べたら CloudWatch は他でつかえねーでやんの。
ログ集約の CloudWatch Logs もダメ。もうダメダメ。
もうね、ちゃんと最初から設計ちゃんと考えとけよ。なにがアジャイル開発だよ。
26歳3年目 転職を考えてる。
持ってる資格
Oracle Bronze,Silver
統計検定2級
大規模構築経験あり
仮想基盤やAWS,Azureのパブリッククラウドの構築経験あり
ミドルは、bind,sendmail,samba,nginx,Apache,Zabbix,LDAPとか
麻雀(天鳳)が趣味で、牌譜の解析とかやりたかったから統計を勉強して、資格にチャレンジしてみた。ついでにpythonと数学も。どちらも業務で使うことはほぼない。
趣味Webメディア作ってたから、Wordpressサイト作るくらいなら一晩で出来る程度の能力。