  |
はてなキーワード: NICとは
生成AIが直接機械語やバイナリを出力するようになるのではないか、という問いは本質的に間違っている。
自分は、まだ素朴なニューラルネットワークで光学文字認識(OCR)の精度を出していた頃から似たようなことを考えていたので、少し他人よりも蓄積がある。
これは、Large Language Model(LLM)を開発する企業が資金を集めるために多少誇張した未来を語るという文脈では大目に見た方が良いが、正確性に欠ける。
本質的な問いは、なぜ我々は、ノイマン型コンピュータを用いて、主記憶に置かれたプログラムをCPUを用いて実行する形式をとるのか、というものである。
まず、筋の悪い反論から説明し、妥当な反論にも触れたうえで、本質的に問うべき課題を説明する。
これは明確に、いいえ、と答えることが出来る。
最初こそ人間による補助は必要だが、LLMを含むAIは明確な目標があれば人間のデータなしでも十分に学習することが出来る。
これは身近なところでは将棋、有名なものだと囲碁で実証された研究が存在する。
そのため、単純に「機械語は人間による学習データが少ないので扱いが難しいだろう」という反論は成立しない。
そういったものはLLMではないだろうという指摘は可能だが、LLMでそういったAIを出力することは限定的とはいえ現在でもできる。将来できないと言うだけの論拠にはならない。
英語に限った話ではなく、人間が意思疎通に用いる言語である自然言語(natural language)は、曖昧さやばらつきがある。
これを形式言語(formal language)という、曖昧さを無くして語彙や文法を限定した言語に記述しなおすことで、厳密にする手法がある。
この形式言語での表現が、アルゴリズムやデータ構造になり、現代のノイマン型コンピュータにおけるプログラムそのものと言うことが出来る。
なぜ限定的かと言えば、形式言語の一種であるプログラミング言語には曖昧さが許容されているからである。
ほとんどのプログラミング言語では、同じ目的を達成する為に複数の記述が許容されている。
主に、人間が書きやすいから、とか、複数の人間で書きやすいように、といった理由で、曖昧さが許容されている。
そのため、機械へ命令するためには厳密さが必要だからプログラミング言語が必要だ、と言う反論は妥当ではあるが、弱い。
なぜ大統一プログラミング言語のように、自然言語の意図を機械に伝えるための形式言語が一種類になっていないかと言えば、人間の認知能力には限界があるからだ。
そのため、簡易で曖昧さを含むために最適化はできないが十分な性能を持つプログラミング言語や、非常に複雑で記述量も多くなるが大人数で作業するには最適なプログラミング言語などが複数存在する。
これらはいずれも、人間が楽に記述できる形式言語であったり、人間同士が齟齬なくコミュニケーションを取るために必要な形式言語である。
ありていに言って、人間や人間たちが理解可能な形式言語でないと機械にその意図を伝えることが出来ないから、と言える。
ただし、コンパイラから出力されたニーモニックやLLVM-IRを監査できる人間は現代では非常に少なく、現状ほぼ監査なく受け入れていると言って良い。
何故非常に少なくなったかと言えば、機械に伝える意図が大規模になり、単純にマンパワーが足りなくなったので監査しきれなくなっただけに過ぎない。
（もちろん、途方もない努力の末に最適化が進み、ほぼどの様な書き方をしても最適な機械語が出力されるようになったから、とも言える）
同様の理屈で、単純に大規模になり監査が間に合わなくなったので、受け入れるようになる未来が来ないとは言い切れない。
本質的な問いは、なぜ我々はノイマン型コンピュータを用いて機械に意図を伝えるのか、である。
ASIC(Application Specific Integrated Circuit)と呼ばれる、特定の用途向けの集積回路がある。
蟹チップとして、Realtek社のNIC(Network Interface Card)をご存じの方も多いと思う。
必要十分な処理があらかじめ定まっているのであれば集積回路を組んだ方が高効率省電力にできる。
暗号化や復号もASICで行われることが多く、ブロック暗号はその性質上集積回路での実装が容易であり、それに向けた研究も行われている。
一般的にも、ハードウェアエンコーダーなどでお世話になっている人も多いと思う。
ではなぜ、我々は身近な全てをASICにしないのか。
それは、書き換えできず、単純な処理しかできず、大量生産しないとコストに見合わないからである。
FPGAのように、ハードウェア記述言語を用いて集積回路を書き換えるものも、ほぼ同様の理由で研究開発用途や産業用途に留まっている。
（一部のPLD (Programmable Logic Device)は根強く産業利用されているし、大規模に展開され高効率を要求されかつ書き換えを求められるネットワーク機器では一部採用が進んでいる）
汎用的で書き換えが可能、伝える意図を変更できる様々な処理が可能な機械に価値があるから、である。
ここ半年から1年で急激にLLMの性能が上がったと感じている人と、コーディングツールとしてLLMの利用が洗練されたと感じている人の間には溝がある。
自分は、LLM自体は順調に進歩し続けているが、それほど劇的な変化はない、という立場をとっている。
これはモデルそのものが質的に大きく変化したと感じないから、である。
しかし、プログラミングの世界に限って観ると、コーディングエージェントや実利用では大きな変化があったと思う。
この、"コーディングを取り巻く環境としてのLLM利用"という文脈は、"LLMの進化"という文脈とは異なる、という点は頭の隅にでも覚えて帰ってほしい。
これは、LLMから直接と言う意味であれば、個人的にはNOだと思う。
ただし、LLMに指示すればバイナリが出力されるという意味であれば、個人的にはYESと答える。
この二つは明確に異なるので、今後自分の意見を述べる際には区別すると良いと思う。
コーディング周りの環境が劇的に整備されつつある、という話題に軽く触れたのはこのためで、LLMが直接バイナリを出力しなくても、結果が同じであれば人々はそれほど気にしない。
例えば、現時点でもローカルのLLMに指示するとGO言語で書かれたコードが生成され、ローカル環境に合わせたシングルバイナリが出力される一連のパイプラインを組むことはできる。
自分の想定する、未来のAIがバイナリを直接出力するというのは、この延長にあると思う。AIがイコールLLMである必要はどこにもない。
少しでもクラウド上でのサーバー処理について触れると、廃棄容易性(Disposability)は俎上に上がる。いつでも落とせていつでも捨てられる、という性質のことである。
こうした、単機能バイナリをコンテナ等に載せて処理し、日に数度デプロイするような環境だと、LLMがバイナリを出力するというのもそれほど遠い未来の話には思えなくなる。
LLMが機械語を出力する未来は個人的には来ないと思う。それは難易度が高いからではなく単純にメリットが少ないからである。
ただし、パイプラインが組まれた一環として、LLMがバイナリを出力する未来は、それほど不思議には思わない。現時点でも可能である。
単純なLinterから進んで静的解析や、動的な結合試験が組み込まれているCICDパイプラインが珍しいとまでは言えない現代において、来るべき近未来像としては妥当性がある。
（その場合、ソースコードはログとして機能し、テキストで保管が容易な、次回以降変更可能なコンテキストの一部になるだろうと思う。今後変更不要ならHDLでFPGAを弄った方が早い）
現代人のすべてがJavaで同一の書き方をしているのではない現状において、自然言語では揺らぎが強すぎて形式言語ほど意図を機械に伝えきれないという反論は、弱い。
それよりは、現代のLLMはコンテキストウィンドウが人間の数倍～数十倍程度で、適切に分割して処理しなければならず、大規模なソフトウェアを丸ごと扱えるほどではない、という反論の方が適切である。
ただ、LLMに適したプログラミング言語が生まれるのではないかと言う予測には懐疑的である。既存のプログラミング言語を使う方が人間が読みやすい。
AIが、人間が欲しいバイナリに適したプログラミング言語をLLMを用いて書き、LLMを用いてレビューし、テストツールでテストし、コンパイラでビルドし、ツールでデプロイし、実稼働するという未来予想図が、荒唐無稽とは思えない。
LLMに適したプログラミング言語が生まれる未来よりも、(冗長であっても)人間可読性の高いコードやSelf-documenting codeが生成される未来の方が、来そうに思う。
また、おそらくこの文章のもつくであろう「どんなプロンプトで書いたのか」という、一定以上の長さの文章はLLMが出力しただろうと仮定する人間が増えている(そしてある程度の妥当性がある)現状において、プロンプトで指示してデプロイまでされる未来はそこまで遠いとも思えない。
ただ、購入できるハードウェアの性能とコストが律速になるので、よほど特殊な(CPUやGPUの設計をLLMが劇的に改善する)状況にならない限り、5～10年はプログラマーが消えることは無いと思う。
金に糸目をつけないのであれば、再来年当たりからはLLMレビューのみで仕様バグ以外のほぼ無いプロダクトが世に出てもおかしくは無いと思う。
何で自分でやらないの？URLたくさん貼ったらとうろくできねーだろ
Reuters, CNN, AP通信, The Guardian, AI Jazeera, BBC Persian
Center for International and Security Studies at Maryland (CISSM), IranPoll, 米国国家情報会議（NIC）年次報告, SNS観測（Telegram, Discord, X 等）, 現地NGO報告（翻訳経由）その他諸々
3つのAIで調べてから要約してもらったうえで、見やすくしたもの↓
内容：空爆・ミサイル攻撃による直接的な恐怖、逃げ場のなさ、家族の安否への懸念。
具体的声：
・「家全体が煙と砂ぼこりで埋もれ、息ができなかった」（45歳男性）
・「サイレンが鳴るたびに地下鉄に避難して夜を明かしている」（都市部在住者）
背景：
・イラン都市部は軍事・政治施設が集中しており、市民生活と攻撃目標が地理的に近接。核施設周辺の住民も強い危機感を持っている。
・また、イランでは戦時にしばしばインターネット遮断が行われ、情報が入らずパニックが助長される。
内容：通貨をドルに替える、ガソリンを買い込む、地方への一時避難、国外逃避の検討など。
具体的行動：
背景：
イラン経済はすでに制裁と国内インフレで疲弊しており、今回の紛争によって更に混乱。生き残るための合理的判断として「逃げる」「備える」が行われている。
3. 現体制への不満と“崩壊への期待”（体感 1〜2割、一部層）
内容：紛争が政権崩壊の契機になるのではという期待。一部では、イスラエルによる体制中枢への打撃を「歓迎」する声すらある。
具体的声：
・「50年近く国民を苦しめてきた独裁体制が終わるかもしれない」
背景：
これらの声は主に若年層や反体制的な市民からであり、普段から女性の権利運動や政権批判に関与している人々に多い。
とはいえ、こうした意見はイラン国内では危険を伴うため、公に表明されることは稀で、ネットや非公開チャット空間で語られている。
4. 政権支持派による報復要求とプロパガンダ的熱狂（体感 1割未満、しかし可視性が高い）
内容：街頭での「イスラエルに死を」などのシュプレヒコールや、国営メディアによる報復支持キャンペーン。
具体的様子：
背景：
ただし、デモは国営メディアの報道ほどには市民の心を動かしていない。地方やオンライン上では冷めた反応も多く、「声が大きいだけで主流派ではない」という見方がある。
＿＿＿
メモ：
「プロパガンダや声の大きいだけの人を可能なら除いて、中立的に」と指示した
AIは、ChatGPT3o, Claude4sonnet,Gemini2.5 ChatGPTだけ課金、要約はChatGPT4（3oは読みづらい）
ソースを出してもらうこともできるが、たぶん読めないしソースの評価もできないのでしていない、まあそれなりだと思われる
廃課金すればもっとよくなるかもしれないけど、そもそもインターネットソースへの信頼度に限界があると思われる
＿＿＿
何で自分でやらないの？URLたくさん貼ったらとうろくできねーだろ
Reuters, CNN, AP通信, The Guardian, AI Jazeera, BBC Persian
Center for International and Security Studies at Maryland (CISSM), IranPoll, 米国国家情報会議（NIC）年次報告, SNS観測（Telegram, Discord, X 等）, 現地NGO報告（翻訳経由）その他諸々
A.
・イラン国内の報道機関は政府の厳しい統制下にあり、市民の本音や批判的な意見を自由に出すことが困難です。
・一方、Reuters、BBC、CNN、Al Jazeera などは現地協力者や匿名取材網を通じて比較的リアルな声を拾っています。
A.
ほらよ
＿＿＿
個人的な最初のモチベーションとしては、TikTokでイスラエルのミサイル動画見てたら
コメント欄で「イラン在住だけど周りの人はイランへの攻撃に喜んでる。なぜなら皆政府が嫌いだから」みたいなコメントがあって激論（※低レベル）が繰り広げられてたんだよね
これは再インストールかなあ。
まさか復旧にネットワークが必須というアホなモジュールをubuntuが採用するとは思わなかった。
いかれてるよ。
いつものようにsambaとteratermでubuntu24 LTSにアクセスして作業していたら突然の切断。
そして起動しない。
mount /snap/core22/1908: special device /var/lib/snapd/snaps/core22_1908.snap does not exist.
can't look blockdev
みたいなエラーメッセージが出ていて、よくわからないけどネットワークブートをしたいのか1分カウントダウンをしていた。
ただし、NICを認識していないっぽくてネットワークには出れない。
しかないので、エラーメッセージを手で描き移すという原始人みたいなことをしながらchatgpt先生に聞いてみると、どうやらsnapdが壊れてしまったみたいだ。
このSSDを別のマシンに刺してみると、パーティションは生きているmountもできる。
とりあえずtarでバックアップを取った。SSDのデータは無事らしい。
さて復旧なんだけど・・・これができないんだよな。
/var/lib/snapd/snaps/core22_1908.snap がないならコピーすればいいじゃんということでコピーを試みるも、正常に動作するubuntu24マシンにはそんなファイルはない。
同じUSBからインストールしたOSのはずなのに意味わからん。
しかたないので、chrootしてsnap refresh coreを実行することにした。
sudo mount --bind /dev /mnt/dev sudo mount --bind /dev/pts /mnt/dev/pts sudo mount --bind /proc /mnt/proc sudo mount --bind /sys /mnt/sys sudo chroot /mnt # chroot内で snap refresh core
chatgptがいうにはこうやると復旧できるらしいが、失敗!
error: cannot communicate with server: Post "http://localhost/v2/snaps/core": dial unix /run/snapd.socket: connect: no such file or directory
やはり、ちゃんと動く方のubuntu24には snapdはいないようだ。
パーテーションもちゃんと見えるのに、grubとかでkernelは起動しているのに、snapdとかゴミが正しく動作しないだけでOSの再インストールをしないといけなさそうだ。
余計な手間を増やすんじゃないよ。
ubuntuインストーラーのUSBをさして、nic認識させたらCtrl+F1..F6とかでインストーラーから飛び降りてmountして復旧する作戦も試してみた。
snap refresh coreを発行するとやはりエラー。
もう知らん消すと apt purge snapd とやった。
そしたら起動時のエラーは消えたけどやはり緊急モードでしか起動しない。
もういいよ。バックアップを取っているし、再インストールしよう。
要するに1Gbpsと10Gbps論争
最近は10Gbpsを諦めて2.5Gbpsになってきているので、1Gbps越え論争の方が正しい
5/10Gbps提供はかなり広まっているのでここはそんなに問題無い
価格も1Gbpsと大して変わらない
実測としては10Gbpsは絶対に出ないが、2〜3Gbpsなら出る
ただし、それはスピードテストをしたときの話であってEnd-to-Endでそれだけでるかどうかは全く別の話になる
10Gbpsは依然としてまだまだだが、1Gbpsを越えるという意味では使えるようになってはいる
またType-C接続のRJ-45ドングルも2.5Gbps対応が出てきている
ノートPCだけでなくスマホでもWiFi 6（11ax）対応が増えてきている
11axなら理論上は最大9.6Gbps使えるが、これは160MHz帯域を8本同時利用した場合で、そんなPCは無い
現状では2本同時利用なので2.4Gbpsが上限となるので、1Gbps越え通信は可能である
本題のアプリケーションだが、単体で1Gbpsを越えるような通信をするアプリケーションは存在しない
8K映像を非圧縮で送れば72Gbps必要だがH.265だとせいぜい100Mbps、将来的な規格では50Mbpsほどまで圧縮できる
10部屋あって全員が8K映像を同時視聴すれば1Gbpsを越えるかもしれない
オンラインゲームでは遅延を嫌ってUDPでバカスカ送ることもあるが、それでも100Mbpsもあれば十分である
非圧縮で送るとコーディング遅延がなくなるが、そもそも伝送遅延がバカみたいに大きいので圧縮しても大差が無い
一方でファイルなどの送受信では帯域幅がそのままダウンロード・アップロード時間に直結する
5GBのイメージをダウンロードする時間は1Gbpsから2.5Gbpsにすればまぁ半分ぐらいにはなる
オンラインストレージをバカスカ使う人にとっては1Gbps越えが魅力的に思えるのだが
実際にはソフトウェア側の工夫（キャッシュなど）によってそれを体感できるかどうか怪しい
実際にDropBox, iCloudやOneDriveはどれもよくできているので帯域幅による違いを感じにくい（細すぎるとダメダメだが）
モデムで28.8kbpsで頑張っていた頃は1Mbpsも出れば夢のような未来が待っているという期待があった
ADSLで1〜10Mbpsもつかえ始めると「1Gbpsも使えるの？」と思っていたが実際には10Mbps越えの通信は十分に需要があった
なので今、「1Gbps以上必要あるの？」と思っていても、将来的には必要になるかも知れない
否定はしないが、1〜10Mbpsの頃から4Kや8Kの話やクラウドストレージのような話はあって
将来的に1Gbpsが使えたときの利用方法は山のように案があった
今、10Gbpsの利用法として合理的なものは知る限り全くない
特にコーディングに関する技術が進みすぎて映像伝送に帯域が不要となったのが大きいように思う
何より1Gbpsの状況が10年以上続いているのが好例だと思う
特に5Gでモバイル網のスピードが固定網に追いついてしまっているので
ハンドオフ等を考えれば全て5G（もしくは6G）でカバーする方が接続性・速度ともに満足度が高い
5Gアンテナを多人数で共有している限りは速度上昇は見込めないので
この業界に求められているのは5GC内蔵の屋内5GプライベートアンテナをeSIM認証で自由にハンドオフできる世界線だと思う
PCにeSIMが入るようになれば屋内でも屋外でもシームレスにネットワーク接続できるし
スタバでWiFiに繋がらなかったりドコモフリーWiFiに勝手に繋がってLINEが来ない、という未来もなくなる
ただ、そのときであっても家庭の屋内配線は1Gbpsで十分である
マンションや店舗のように複数人で共有するなら当然1Gbps以上の回線が必要だが、伝送距離を考えればファイバーの方が有利である
この記事の主旨は「ウクライナのゼレンスキー大統領のパーカーは略式軍服である」ということではない。
あくまで「略式軍服という日本語はなかった」「一年ほど前から急に現れた言葉だ」という誤認を訂正したいだけである。
「略式軍服」という言葉の使用例は、国立国会図書館デジタルコレクションの全文検索では33件 - 法華狼の日記
どう見ても定着した言葉や概念ではない。ほとんどが翻訳で採用された言葉だったり、あくまで「略式の軍服」という意味の表現にすぎない。同一作品の重複も多い。
法華狼氏のエントリでは近年の用例はないとされているが、実際にはそうした用例は存在する。
枯野瑛『終末なにしてますか？ 忙しいですか？ 救ってもらっていいですか？』
あえて翻訳は除外したが、日本人作家の商業作品に限定してもこうしていくつかの使用例がある。
池波正太郎以外は、2000年ごろから2020年までに刊行された新しい書籍である。
もちろん10件足らずでは「定着していた」とまでは言えない。
しかし「用例がまったく無いわけではない」ということはわかるはずだ。
「用例」の存在を確認したところで、次は「用法」の確認をしたい。
国立国会図書館デジタルコレクションで「略式軍服」を検索すると、1940年発行の岡倉由三郎編『新英和大辞典』がヒットし、以下のような項目を見つけることができる。
tu'-nic [tjúːnɪk] n. 1) 〘古代ギリシャ・ローマ〙襦袢, 肌着, シャチ; 2) 一種の陣羽織; 3)（現代婦人の用ひる）腰部緊着上衣; 4) 〘俗〙密着短上衣, 略式軍服（又は, 警官服）; 5)〘解・動〙被膜, 膜（＝integument）; 7)〘植〙膜質外皮, 種皮（＝husuk）. [OF tunique, ＜ L tunica]
つまり辞書レベルで「略式軍服」は「（軍服の）チュニック」の訳語だったのである。
これは法華狼氏が「ほとんどが翻訳で採用された言葉だった」と書いているのにもつながる。
実際に、国立国会図書館デジタルコレクションで読めるいくつかの翻訳書籍の原文を確認してみると、
エリック・アンブラー著・宇野利泰訳『真昼の翳』（1963年）
He stood up, as if to end the discussion, and smoothed down the front of his tunic.
when he came back he looked lovely in his uniform, with all those pretty ribbons on his tunic,
コーネリアス・ライアン著・木村忠雄訳『ヒトラー最後の戦闘』（1966年）
Golbov took out of his tunic pocket a folded copy of the newspaper Red Star
用例が少ないために「それが定訳だった」とまでは言えないかもしれないが、「チュニックを略式軍服と訳していた」ということの証左にはなっていると思う。
古くは「チュニック」の訳語とされ、近年でも数は少ないながら商業作品に使われている。
[自社開発メガベンチャーをわずか半年で鬱退職した雑魚エンジニアの話｜JoanOfArc](https://note.com/joan_of_arc/n/ned510ca913c7)
1. 今はなき鉄鋼メーカー、研究所で新規シミュレーションコード立ち上げ
メンターが米国自動車メーカーへ転職して途方にくれた。電磁気学の教科書を読み漁って掲載されているサンプルコードを理解して、コード手打ちして3ヶ月で動く様にした。社内で誰も見たことが無い結果に驚かれた。
2. 鉄鋼メーカーの人員削減が若手にも迫ってきたので、電子部品メーカーへ転職。コードは書かず開発現場で製品試作品の制作をモクモクと行う。
3. 色々あってプログラマー派遣会社へ転職。ドコモ向けのアプリのテストデータを作成するだけの仕事をアサインされた。楽勝の仕事だったが、拘束時間が長く半年で10kg太る。
4. 派遣で今はなきシャープ常駐でデジカメファームウェアの開発現場に放り込まれる。C言語の未知のコードとLSIの仕様書に戸惑ったが、親切な若手社員に助けてもらって独り立ち出来た。2年程やったが、雇い止めに合った。
VC++製の画像処理アプリもメンテした。VBの画像処理アプリも自作した。
5. 現NTT、当時住友銀行子会社で常駐で電磁界シミュレーションアプリの新機能開発を担当。分散処理による計算時間短縮を狙う部分を担当。分散処理はMPI(現OpenMPI)を使用。まずはパソコン2台で分散処理を行うもNIC(LAN Card)がボトルネックで計算は出来るが1台で計算するよりパフォーマンスが出なかった。職場にジョインしたあとは、しばらくは訳がわからず、戸惑った。通勤時間が長く体が消耗した。
派遣プログラマーは嫌で正社員で働きたかったので、プログラマーにこだわらず職場を探した。知財の職に採用されたので、常駐先と派遣会社に退職を願いでると引き止められて困った。退職を強行して転職できた。離職票の入手に苦労した。暑い夏だった。
6. 中小製造メーカーの知財の職場では要領よく仕事をこなしていると時間があまる。余った時間で社内WEBサイトを作ったりした。使ったのはASP(ASP.NETの前身、VB.NETでコーディング)。フレームワークに従ってコードを埋めるとそれなりに動いた。DBMSはAccessを使った。要するにmdbファイルにデータを保存した。更新処理は管理者のみ、データの閲覧が主な機能であるWEBサイトだった。
7. 知財の仕事は楽勝なのだが、やはり開発の仕事に未練が出てきた。iOSアプリの開発もやってみたくなった。10年以上知財の仕事を行ったが思い切って無職へ転向した。親父も無くなり、遺産の整理もサラリーマンを行いながら難しかったのだ。(つづく)
仮想システムを構築するにあたり、CIFS しか使えない NAS をバックアップ用に選定してきた SI 屋さんが居たので、CIFS と iSCSI のどちらが早いのか、試してみました。
テストに使う NAS は QNAP の Turbo NAS TS110
http://www.tekwind.co.jp/products/entry_6719.php
です。もう６年以上愛用して、カビが生えてもおかしく無い程に古いし, 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 デバイスで複数作れるので、１台の 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 バスアダプタに７番のIDを振り、残りの 0 ~ 6 のディスクや CD, Tape などに ID を振り分ける物理的な３ビットのディップスイッチやジャンパ端子が付いていました。これが SCSI アドレスです。
これが実に難物でした。特に、複数の SCSI バスアダプタカードをデュプレクス設定する場合、割り込み番号も別々にするので、手が滑ってジャンパピンを飛ばして床を這いまわって探したり、難解なディップスイッチを前に数日悩んだものです。
つまり一つのSCSIバスには 0~７の合計８台（うち大抵７番は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に繋げる事と同じことですね。
ＰＲ
ちなみに opeSUSE で使うにはこんな感じになりました。
open SUSE Leap 15.1 で iSCSI NASを使ってハマった
https://islandcnt.exblog.jp/239328437/
一番イラつくのは、巨大なファイルの転送でしょう。という事で 3G 程ある SUSE Linux のインストール用DVDの ISO ファイルを CIFS でコピーしてみます。
仮想化時代の NAS 選び - やっぱり iSCSI は早い。_a0056607_16414334.jpg
３分１１秒かかりました。１Gビットネットワークで 12～3% 程度の帯域を使って通信しています。明らかに古いNAS の性能が足を引っ張っているようです。
スループットは 150Mbps 程度で全体の最大１５％程度でしょうか。
仮想化時代の NAS 選び - やっぱり iSCSI は早い。_a0056607_16415832.jpg
仮想化時代の NAS 選び - やっぱり iSCSI は早い。_a0056607_16422170.jpg
初速は出るのですが、その後は、ボロイ TS-110 の性能がモロに出ます。それでも 20 MB/s から 25 MB/s 程度は出ています。
仮想化時代の NAS 選び - やっぱり iSCSI は早い。_a0056607_16423835.jpg
２分２５秒でした。 大体２０％程度のスループットです。
--
数字に弱い私の脳みそですが、 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が２ポート以上のものが推奨されます。
iSCSI はあくまでもネットワーク上のストレージのみの機能を提供するものであり、ファイル共有の手段ではない、という事です。
NAS をCIFSで使うと NAS が持つ独自のアクセス権限を設定しなければなりません。セキュリティも当然 NAS 独自の機能で設定します。
iSCSI はあくまでも「外付け SCSI デバイス」のネットワーク版なので、マウントする側のOSそのもののファイルシステム、セキュリティ機能、アクセス制限がホスト側の機能をそのまま利用できます。セキュリティ的には、マウントする際のパスワード制限しかないので、独自のストレージネットワーク内に配置すべきで、ユーザが使う構内ネットワークに配置すべきではありません。
言うて中国あたりがなりすます用に取得して住所が謎のマンションとかやろと思ったら本物でワロタ
[Registrant] Yahoo Japan Corporation
[Name Server] ns01.yahoo.co.jp
[Name Server] ns02.yahoo.co.jp
[Name Server] ns11.yahoo.co.jp
[Name Server] ns12.yahoo.co.jp
[Signing Key]
[登録年月日] 2008/08/29
[最終更新] 2020/09/01 01:05:08 (JST)
Contact Information: [公開連絡窓口]
[Name] Yahoo Japan Corporation
[Email] nic-admin@mail.yahoo.co.jp
[Web Page]
[郵便番号] 102-8282
[Postal Address] 1-3 Kioicho, Chiyoda-ku
[電話番号] 03-6898-8200
[FAX番号]
・何も言ってないのに中国が反発したｗ
さすがとしかいえん
【ワシントン=永沢毅】米国家情報長官室は27日、新型コロナウイルスの発生源に関する調査報告書の要旨を公表した。①動物から人間に感染②中国のウイルス研究所からの流出――の2つのどちらかを結論づける決定的な証拠を得られず、特定できなかったと説明した。真相解明には中国の協力が必要と指摘した。
バイデン米大統領は声明で「透明性を求める意見を中国は拒否し、情報を提供しないようにし続けている。完全に情報共有するよう各国とともに圧力をかける」と強調した。中国の反発は確実だ。
要旨によると、起源は2つの仮説のどちらかが妥当としながらも「情報機関の意見がわかれている」と表明した。4機関および米大統領の諮問機関である国家情報会議（NIC）は動物からの感染と分析し、別の1機関は中国の武漢ウイルス研究所からの流出を支持する見解を示した。
さらに別の3機関は追加情報がなければ判断できないとした。ウイルスが生物兵器として開発されたものではないとの見解では一致し、遺伝子が操作された可能性も低いとの見方を示した。
そのうえで「新たな情報を得られない限り、起源についてより信頼性の高い説明ができない」と説明した。中国は情報の共有を拒んでいるとして「中国政府のこうした行動は、国際社会からの圧力へのいらだちに加えて調査の進展に不安を抱えていることの表れである」と記述した。
要旨は2ページで、報告書の大半は機密情報扱いのため公表されていない。バイデン氏は5月末、発生源を巡る追加調査と90日以内の報告を米情報機関に指示し、今週に報告を受けた。
俺のカンだと、デバイスドライバで見れるネットワークドライバはRealtek製だろう？
以前個人的に調べた限りでは、Windows 10で一部のRealtek製のWi-Fiチップを用いたNICを使う場合にその現象が起こるようだ。
自分の場合は自作デスクトップPCの話だが、RTL8192CUのUSB無線子機(IOデータWN-G300UA)と、RTL8812BUのUSB無線子機が頻繁な切断現象に陥った。
"RTL8192CU disconnecting"みたいなワードで検索すれば海外では認識されている問題のようで、それを参考に公式から旧バージョンのドライバを適用することでほぼ安定することを確認したが、Windowsの自動アップデートによってドライバが上書きされると再発してしまうので、結局Intel AX200NGWを積んだPCI-eアダプタを導入することで解決した。
安定性が高いのはIntel製のWi-Fiチップを積んだものだが、市販品はどこ製のチップを積んでいるか書いていないものが多い上、USB型はだいたいドライバダウンロードしてみるとRealtekだ。
ノートPCの場合俺の買ったようなPCI-eアダプタは使えないが、自分で分解してM.2型のWi-Fiモジュールに交換することができるかもしれない。この際11ax対応のにルーターごとアップグレードしてみるとか。
