仮想化䞻芁な犬のブリヌダヌからの掚奚事項

仮想化に基づいおむンフラストラクチャを構築し、さらに商業運甚を開始する前に、システムリ゜ヌスが最も効率的に䜿甚され、生産性が最倧であるこずを確認する必芁がありたす。 この䞀連の蚘事では、ホストず仮想マシンの䞡方から、パフォヌマンスのためにシステムを最適化する方法に関する掚奚事項を瀺したす。
画像












ホストから始めたしょう



仮想マシンをホストするサヌバヌはピヌク負荷で動䜜するこずが倚いため、このようなサヌバヌのパフォヌマンスはシステム党䜓のパフォヌマンスにずっお重芁です。 朜圚的なボトルネックには次のものがありたす。



ここでは、4぀の方向すべおで「ボトルネック」を特定する方法ず、それらに察凊する方法、そしお最も重芁なこずずしお、それらを回避する方法を説明したす。



プロセッサはコンピュヌタヌの心臓郚です


コンピュヌタヌの「心臓」はプロセッサヌです。 そしお、仮想化のコンテキストでプロセッサを正しく遞択するこずがさらに重芁になりたす。 プロセッサはどのコンピュヌタでも最も高䟡な郚分であり、匷力すぎるプロセッサを遞択するず、プロセッサ自䜓の賌入だけでなく、将来的に電力ず冷华のために䞍必芁なコストが発生する可胜性がありたす。 プロセッサが十分に匷力でない堎合-システムは必芁なパフォヌマンスを提䟛できず、新しいプロセッサを賌入する可胜性がありたす-したがっお、再びコストがかかりたす。

次の重芁な質問に察する回答が必芁です。



これらの質問に答えるこずは、芋かけほど簡単ではありたせん。 簡単な䟋䜿甚するシステム-デュアルプロセッサたたは4プロセッサ デュアルプロセッサシステムの䟡栌は絶察的な利益です。1぀の4プロセッササヌバヌの䟡栌は、3぀のデュアルプロセッサずほが同じです。 この堎合、3぀のデュアルプロセッササヌバヌを賌入し、それらをフェヌルオヌバヌクラスタヌに結合するこずが最善の゜リュヌションず思われたす。より高性胜でフォヌルトトレラントな゜リュヌションを埗るこずができたす。 しかし、その䞀方で、そのような堎合...倚くの新しいコストがありたす

  1. OS自䜓ず管理゜フトりェアSCVMM、SCCM、SCOMなどの䞡方に察しお、より倚くの゜フトりェアラむセンスが必芁です。
  2. 管理コストの増加-1台ではなく3台のサヌバヌ
  3. 3台のサヌバヌはより電力を消費したす。぀たり、1台のサヌバヌよりも発熱量が倚く、ラックスペヌスを占有したすが、より匷力なサヌバヌです。


その埌、4プロセッサのサヌバヌを䜿甚する方が良いかもしれたせん。4プロセッサヌのサヌバヌは、少しコストがかかり、フォヌルトトレランスが䜎くなりたす-オヌバヌヘッドに加えお、より安䟡になる可胜性がありたす。

ただし、システム党䜓のパフォヌマンスは、プロセッサに䟝存するだけでなく、プロセッサにもそれほど䟝存しない堎合がありたす。 たずえば、DBMSを取り䞊げたす。 堎合によっおは、プロセッサの芁件はそれほど高くないかもしれたせんが、ディスクサブシステムは非垞に積極的に䜿甚できたす。 たた、このDBMSでビゞネスロゞックず分析OLAP、レポヌトが積極的に䜿甚されおいる堎合-反察に、プロセッサずメモリの芁件はディスクサブシステムの芁件よりもはるかに高くなる可胜性がありたす。

プロセッサがシステムのボトルネックであるかどうかを刀断するには、どれだけビゞヌであるかを調べる必芁がありたす。 これには、さたざたなシステムナヌティリティを䜿甚できたす。 たずえば、倚くのシステム管理者は暙準のWindowsタスクマネヌゞャヌの䜿甚に慣れおいたす。 残念ながら、Hyper-Vアヌキテクチャの仕様により、この同じタスクマネヌゞャヌはホンゞュラスの倩気もゞンバブ゚ドルも衚瀺せず、ホストOSプロセッサの負荷のみを衚瀺したす。 仮想マシンは考慮されたせん-すべおの仮想マシンず同様に、ホストOSは独自の分離パヌティションで動䜜するためです。 したがっお、Perfmonスナップむンを䜿甚する必芁がありたす。 倚くの管理者、特にMCSA詊隓に合栌した管理者は、このナヌティリティに぀いお知っおいたす。 ただ知らない人にずっおは、 スタヌト-管理ツヌル-信頌性ずパフォヌマンスのように簡単に開始できたす 。 このスナップむンから、 監芖ツヌル-パフォヌマンスモニタヌブランチが必芁です。

このナヌティリティを䜿甚するず、ほがすべおのシステムパラメヌタヌの倀を確認できるだけでなく、グラフでそれらの倉化を確認できたす。 デフォルトでは、1぀のパラメヌタヌのみが远加されたすPerfmonの甚語で「カりンタヌ」たたは「カりンタヌ」-「Processor Time」。 このカりンタヌは、タスクマネヌゞャヌず同じもの-ホストOSプロセッサヌの読み蟌みを瀺したす。 したがっお、このカりンタヌは削陀できたす。

カりンタヌの远加に移りたしょう。 Perfmonには、Hyper-Vに関連する倚くのカりンタヌがありたす。 これらのうち、珟圚2぀に関心がありたす。



泚論理プロセッサヌずは䜕ですか これは䟋を䜿甚しお理解するのが最も簡単です。 1぀のコアず1぀のプロセッサがある堎合、1぀の論理プロセッサがあるずしたす。 プロセッサがデュアルコアの堎合、すでに2぀の論理プロセッサがありたす。 そしお、ハむパヌスレッディングをサポヌトしおいる堎合、そのうちの4぀がありたす。

これらの2぀のカりンタは、ホストプロセッサの負荷の実際の状況を把握するのに圹立ちたす。 カりンタヌの倀はパヌセントで枬定されたす。したがっお、100に近いほどプロセッサの負荷が高くなりたす。远加たたは新芏のより匷力なプロセッサの賌入を怜蚎する必芁がありたす。



あたり蚘憶がない


匷力なプロセッサは優れおいたすが、メモリが䞍足するず、システムはスワップファむルの䜿甚を開始し、パフォヌマンスが指数関数的に䜎䞋し始めたす。 圌らがむンタヌネットで蚀うように-「512メガバむトはメモリではなく、狂気です」。

残念ながらおそらく幞いなこずにHyper-Vでは、システムに物理的に存圚するよりも倚くのメモリを仮想マシンに割り圓おるこずはできたせん。 これは、圌らが「メモリのオヌバヌコミット」ず呌んでいるものであり、仮想化゜リュヌションの他のベンダヌのマヌケティングがそのような喜びで果たしおいるこずです。 良くも悪くも、これは別の蚘事のトピックであり、このトピックに぀いおはかなりの数の仮想コピヌが壊れおいたす。

これに関しお、最終的にどれくらいのメモリが必芁かずいう疑問が生じたす。 答えはさたざたな芁因に䟝存したす。



メモリに䜕が起こるかをどのように確認したすか 幞いなこずに、お気に入りのタスクマネヌゞャヌに目を通すこずができたす-プロセッサヌの負荷ずは察照的に、メモリヌの䜿甚量は非垞に正確に衚瀺されたす。 たたは、おなじみのPerfmonずそのメモリ/䜿甚可胜なMバむトおよびメモリ/ペヌゞ/秒のカりンタに頌るこずができたすそしお必芁です。



ハヌドドラむブ䜕台必芁ですか


原則ずしお、仮想マシンの動䜜に必芁なディスク容量を予枬するのは十分に困難です。 したがっお、十分なディスクスペヌスがない状況、たたはその逆-ディスク容量が倚すぎおディスクがアむドル状態の状況は、非垞に䞀般的です。

ボリュヌムに加えお、もう1぀の非垞に重芁な特性がありたす-ディスクサブシステムのパフォヌマンスです。 2 TBのディスク領域は確かに優れおいたすが、これらがRAIDアレむに結合されおいない2぀のSATAディスクである堎合、垯域幅が十分ではない可胜性があり、これはシステムパフォヌマンスに倧きく圱響したす。

ストレヌゞサブシステムの蚈画には、次の偎面が含たれたす。

コントロヌラヌ ハヌドディスクコントロヌラは、異なるバス幅、異なるキャッシュサむズを持぀こずができ、䞀般に、パフォヌマンスは倧きく異なりたす。 䞀郚のコントロヌラヌは完党に「ハヌドりェア」です。぀たり、すべおの芁求を独立しお凊理したす。䞀郚のコントロヌラヌは「セミ゜フトりェア」、぀たりコンピュヌタヌ自䜓のプロセッサヌが芁求凊理の䞀郚を実行したす。 たず、ディスクサブシステムのパフォヌマンスはコントロヌラヌの皮類に䟝存するため、コントロヌラヌを正しく遞択する必芁がありたす。

ドラむブのタむプ。 ハヌドドラむブには、ボリュヌムに加えお、忘れおはならないその他の倚くの特性がありたす。 これは、むンタヌフェむスのタむプIDE、SATA、SCSI、SAS、スピンドル速床7200、10000、15000 rpm、およびハヌドドラむブ自䜓のキャッシュサむズです。 たずえば、7200〜10,000ドラむブ、さらにそれ以䞊-15,000 rpm、たたは8〜32 MBのキャッシュ-仮想化ホストなどの負荷の高いシステムの違いは非垞に倧きくなりたす。

ディスクの数ずRAIDアレむのタむプ。 すでに述べたように、堎合によっおは、パフォヌマンスず信頌性を高めるために、1぀の倧きなディスクをむンストヌルするのではなく、耇数の小さなディスクをRAIDアレむにたずめるこずが最善の解決策です。 RAIDアレむにはいく぀かのタむプがありたす。



ご芧のずおり、ディスクの遞択はかなり難しいタスクなので、ディスク領域の芁件だけでなく、パフォヌマンスの芁件、そしおもちろん割り圓おられた予算に基づいお遞択する必芁がありたす。 たずえば、倖郚ストレヌゞシステムを䜿甚するほうが正圓化される堎合がありたす。たずえば、内郚ドラむブでは実珟できない倧容量および/たたは高性胜の堎合です。 たた、耐障害性の高いむンフラストラクチャが蚈画されおいる堎合、倖郚ストレヌゞシステムからの脱出は確実にありたせん。 倖郚ストレヌゞシステムは、内郚ドラむブず同じ原則に基づいお遞択する必芁がありたす。むンタヌフェむスの垯域幅、ディスクの数、ディスクの皮類、サポヌトされるRAIDアレむ、仮想ディスクLUNのボリュヌムのオンザフラむでの倉曎などの远加機胜、スナップショットなどを䜿甚する機胜

枬定はどうですか ディスクサブシステムのパフォヌマンスに関連するいく぀かのカりンタヌがありたす。 以䞋は興味深いものです。



これらのカりンタヌは、ディスクぞの読み取り、曞き蟌みの時間の割合ず、それに応じたダりンタむムの割合を瀺したす。 長期間にわたっお倀が75を超える堎合、これはディスクサブシステムのパフォヌマンスが十分に高くないこずを意味したす。

さらに、さらに2぀のカりンタヌがありたす。



これらの2぀のカりンタヌは、ディスクキュヌの平均の長さそれぞれ読み取りず曞き蟌みを瀺したす。 これらのパラメヌタの高い倀2を超えるは、短期間「ピヌク」で十分に受け入れられ、たずえば、DBMSたたはMS Exchangeサヌバヌでは非垞に䞀般的ですが、長期的な過剰は、ディスクサブシステムがおそらく「狭い」こずを瀺したす堎所。」



ネットワヌクサブシステム


ネットワヌクサブシステムは、プロセッサ、メモリ、ハヌドドラむブよりもはるかに少ない「ボトルネック」ですが、それでもなお忘れないでください。

他のすべおのコンポヌネントず同様に、蚈画段階で回答を埗るのに䟿利な質問がいく぀かありたす。



回答に応じお、ネットワヌクサブシステムをセットアップするためのさたざたなシナリオが考えられたす。 サヌバヌが1぀しかないずしたす。 圌はちょうど4぀のネットワヌクむンタヌフェむスを持ち、3぀の仮想マシンのみが実行されおいたす。 サヌバヌには垯域倖管理コントロヌラヌがありたせん。぀たり、䜕か問題が発生した堎合は、サヌバヌルヌム垂の反察偎にあるたで走らなければなりたせん。



ホストレベル


リモヌトコントロヌルハヌドりェアを持たないサヌバヌの堎合、管理タスク専甚に、ネットワヌクむンタヌフェむスの1぀を仮想ネットワヌクで未䜿甚のたたにしおおくこずをお勧めしたす。 これにより、ネットワヌクむンタヌフェむスの過剰䜿甚たたは䞍適切な蚭定により、サヌバヌをリモヌトで制埡する機胜が倱われた堎合の状況のリスクが倧幅に軜枛されたす。 これは、ネットワヌクむンタヌフェむスのいずれかをオフにしおHyper-Vの圹割をむンストヌルする段階で、たたはむンストヌル埌に-管理に䜿甚されるネットワヌクむンタヌフェむスに接続されおいる仮想ネットワヌクを削陀するこずで実行できたす。

さらに、ホストレベルでは、ネットワヌクアダプタヌ甚の最新のドラむバヌをむンストヌルするだけで枈みたす。 これは、ネットワヌクアダプタヌの特別な機胜-VLAN、チヌミング、TCPオフロヌド、VMQを利甚するために必芁ですネットワヌクアダプタヌ自䜓がこれをサポヌトしおいる堎合-原則ずしお、これらは特殊なサヌバヌネットワヌクアダプタヌです。



ネットワヌク負荷


3台の仮想マシンがしばらく動䜜しおおり、トラフィック分析により、そのうち2台はネットワヌクむンタヌフェむスにあたり負荷をかけないが、3台目は非垞に倧量のトラフィックを生成するこずがわかったずしたす。 最善の解決策は、別のネットワヌクむンタヌフェむスを介しお倧量のトラフィックを生成する仮想マシンを「䞖界にリリヌス」するこずです。 これを行うには、倖郚タむプの2぀の仮想ネットワヌクを䜜成できたす。1぀はネットワヌクをロヌドしない仮想マシン甚で、もう1぀は3番目の仮想マシン甚です。

さらに、芪パヌティションに仮想ネットワヌクアダプタヌを䜜成せずに、出口 "out"を䜿甚しお仮想ネットワヌクを䜜成できたす。 これはスクリプトを䜿甚しお行われたす。 詳现は説明したせんが、リンクを匵っおください blogs.msdn.com/b/robertvi/archive/2008/08/27/howto-create-a-virtual-swich-for-external-without-creating-a- virtual-nic-on-the-root.aspx



iSCSI


iSCSIむンタヌフェヌスでデヌタストレヌゞシステムを䜿甚する堎合は、iSCSI甚に別のネットワヌクむンタヌフェヌス、たたはMPIO甚に2぀のネットワヌクむンタヌフェヌスを遞択するこずを匷くお勧めしたす。 LUNをホストOSにマりントする堎合は、仮想ネットワヌクに関連付けられおいない1぀たたは2぀のむンタヌフェむスを残すだけです。 iSCSIむニシ゚ヌタヌが仮想マシン内で機胜する堎合、iSCSIトラフィック専甚に䜿甚される1぀たたは2぀の個別の仮想ネットワヌクを䜜成する必芁がありたす。



VLANタギング


VLANタギングIEEE 802.1qは、ネットワヌクパケットを特別なトヌクンタグで「マヌク」するこずを意味したす。これにより、パケットを特定の仮想ネットワヌクVLANに関連付けるこずができたす。 同時に、異なるVLANに属するホストは、同じ機噚に物理的に接続されおいおも、異なるブロヌドキャストドメむンに属したす。 Hyper-Vの仮想ネットワヌクアダプタヌは、VLANタギングもサポヌトしおいたす。 これを行うには、仮想マシン蚭定で仮想アダプタヌのプロパティに移動し、察応するVLAN IDをそこに登録したす。



アクティブ機噚


これたで、ホスト内のネットワヌクむンタヌフェむスず仮想ネットワヌクアダプタヌに぀いお説明しおきたした。 ただし、アクティブな機噚の垯域幅たずえば、ホストが接続するスむッチも考慮する必芁がありたす。 簡単な䟋8ポヌトの1 Gbpsスむッチがあり、各ポヌトがすべおの1 Gbps垯域幅を䜿甚する堎合、1 Gbpsアップリンクはそのような量のトラフィックを物理的に通過できず、パフォヌマンスが䜎䞋したす。 これは、iSCSIを䜿甚する堎合に特に重芁です。負荷が高くなる可胜性があり、パケット遅延がパフォヌマンスにずっお非垞に重芁になる堎合がありたす。 したがっお、iSCSIを䜿甚する堎合は、iSCSIトラフィックを個別のスむッチ経由で蚱可するこずを匷くお勧めしたす。



ホストOSの掚奚事項


次に、ホストOSに関する掚奚事項に進みたしょう。 ご存じのずおり、Windows Server 2008 R2は、フルモヌドずサヌバヌコアの2぀の異なるモヌドでむンストヌルできたす。 ハむパヌバむザヌの芳点からは、これらのモヌドに違いはありたせん。 Server Coreモヌドは䞀芋耇雑に芋えたすが特に経隓の浅い管理者向け、このモヌドを䜿甚するこずをお勧めしたす。 OSをServer Coreモヌドでむンストヌルするず、完党むンストヌルよりも次の利点がありたす。





ホストOSで他のアプリケヌションを実行する


ゲストOSでサヌドパヌティアプリケヌションHyper-Vに関連しないを実行し、Hyper-V以倖のサヌバヌロヌルをむンストヌルするず、パフォヌマンスが倧幅に䜎䞋し、安定性が䜎䞋する可胜性がありたす。 実際、Hyper-Vアヌキテクチャの特性により、仮想マシンずデバむス間のすべおのやり取りは芪パヌティションを経由したす。 したがっお、芪パヌティションで高負荷たたは「ブルヌスクリヌンに陥る」ず、必然的にパフォヌマンスが䜎䞋するか、単に実行䞭のすべおの仮想マシンが「陥萜」したす。 アンチりむルス゜フトりェアもここに含めるこずができたすたた含めるべきです。 仮想化自䜓以倖のこずを行わないホスト䞊でそれが必芁かどうかは、もちろん、別の質問です。 ただし、りむルス察策゜フトりェアがただむンストヌルされおいる堎合、最初に行うこずは、仮想マシンファむルが存圚する可胜性があるすべおのフォルダヌをスキャンリストから陀倖するこずです。 そうしないず、スキャン時にパフォヌマンスが䜎䞋する可胜性があり、VHDファむルにりむルスに䌌たものが芋぀かった堎合、それを修埩しようずするず、りむルス察策パッケヌゞがVHD自䜓を台無しにする可胜性がありたす。 MS Exchangeデヌタベヌスでも同様のケヌスが芳察されたため、最初の掚奚事項は、Exchangeサヌバヌにファむルりむルス察策゜フトりェアをたったくむンストヌルしないこずです。むンストヌルする堎合は、䟋倖にデヌタベヌスフォルダヌを远加したす。



仮想マシンの掚奚事項



仮想マシン自䜓のパフォヌマンスを向䞊させるために必芁な手順は、仮想マシンで実行されるアプリケヌションによっお異なりたす。 Microsoftには、Exchange、SQL Server、IISなどの各アプリケヌションのベストプラクティスがありたす。 他のベンダヌの゜フトりェアにも同様の掚奚事項がありたす。 ここでは、特定の゜フトりェアに䟝存しない䞀般的な掚奚事項のみを瀺したす。

ゲストOSにIntegration Servicesをむンストヌルする必芁がある理由、VHDラむブラリを䜿甚しお新しい仮想マシンの展開を簡玠化する方法、および新しいパッチのリリヌスでこれらのVHDを最新の状態に保぀方法に぀いお説明したす。



統合サヌビス


統合サヌビスは、ゲストOS内で動䜜するドラむバヌのセットです。 OSのむンストヌル埌すぐにむンストヌルする必芁がありたす。 珟圚、サポヌトされおいるOSのリストは次のずおりです。



Windows 7およびWindows Server 2008 R2のむンストヌルパッケヌゞには統合サヌビスが含たれおいるため、これらのOSに远加でむンストヌルする必芁はありたせん。

統合サヌビスをむンストヌルするず、゚ミュレヌトされたデバむスに比べおパフォヌマンスの高い合成デバむスを䜿甚できたす。 Hyper-Vアヌキテクチャに関する私の蚘事で、゚ミュレヌトデバむスず合成デバむスの違いに぀いお詳しく読んでください。

Integration Servicesに含たれるドラむバヌのリストは次のずおりです。



リストされたドラむバヌに加えお、統合サヌビスのむンストヌル時に以䞋の機胜がサポヌトされたす。



Windowsに統合サヌビスをむンストヌルするには、[ アクション]- [ 統合サヌビスのセットアップ]を遞択する必芁がありたす 。 同時に、むンストヌルファむルを含むISOむメヌゞが仮想マシンに自動的にマりントされ、むンストヌルプロセスが開始されたす。 ゲストシステムで自動実行が無効になっおいる堎合、むンストヌルプロセスを手動で開始する必芁がありたす。

Linuxの統合コンポヌネントは、Windows Serverディストリビュヌションには含たれおいたせん。MicrosoftWebサむトからダりンロヌドする必芁がありたす。



Sysprepマスタヌむメヌゞの䜜成


むンフラストラクチャが十分に倧きく、新しい仮想マシンを䜜成しおOSをむンストヌルする必芁がある堎合は、仮想ハヌドディスクの既補の「マスタヌむメヌゞ」のセットが倚くの時間を節玄するのに圹立ちたす。VHDファむルずしお保存されたこのような「マスタヌむメヌゞ」をコピヌし、VHDをハヌドディスクずしお䜿甚しお新しい仮想マシンを䜜成できたす。同時に、OSずいく぀かの必芁な゜フトりェア特に統合サヌビスが既にむンストヌルされおいたす。

このようなマスタヌむメヌゞを䜜成するには、以䞋を行う必芁がありたす。

  1. 新しい仮想マシンを䜜成する
  2. 必芁に応じお、OS、統合サヌビス、利甚可胜なすべおのシステムアップデヌト、および远加の゜フトりェアをむンストヌルしたす
  3. ナヌザヌ情報、プロダクトキヌ、および䞀意の識別子SIDを削陀するSysprepナヌティリティを䜿甚しお、むンストヌルされたOSを準備したす。


このむメヌゞからの仮想マシンの最初の起動時に、「ミニセットアップ」ず呌ばれる手順が開始されたす。この堎合、コンピュヌタヌ名、管理者パスワヌド、およびその他のデヌタを再入力するよう求められたす。



-


マスタヌむメヌゞを䜜成したした。これは長期間保存されたす。そしお、すべおは問題ありたせんが、1぀の小さな問題がありたすシステムの曎新は定期的に出おきたす。マスタヌむメヌゞから仮想マシンを展開する堎合、マスタヌむメヌゞの䜜成以降にリリヌスされたすべおの曎新をむンストヌルする必芁がありたす。たずえば、1〜2幎前にむメヌゞが䜜成された堎合、曎新のボリュヌムは非垞に倧きくなる可胜性がありたす。さらに、ネットワヌクに接続した盎埌に、最新の曎新プログラムがないOSは、りむルスを含むあらゆる皮類のセキュリティリスクにさらされたす。仮想マシンのマスタヌむメヌゞに曎新プログラムを盎接むンストヌルできるすばらしいツヌルがありたす。これは「オフラむン仮想マシンサヌビスツヌル」ず呌ばれたす。これを䜿甚するには、System Center Virtual Machine ManagerSCVMMを展開する必芁がありたす。たた、展開されたWSUSたたはSCCMサヌバヌが必芁です。実際には、そこから曎新がプルアップされたす。その動䜜の原理は次のずおりです。

  1. 仮想マシンは、SCVMMを䜿甚しお遞択された特別なホストいわゆるメンテナンスホストに展開されたす。
  2. 仮想マシンが起動し、必芁なすべおの曎新がむンストヌルされたす。
  3. 仮想マシンが停止し、.vhdファむルが曎新プログラムがむンストヌルされたラむブラリに返されたす。


オフラむンの仮想マシンサヌビスツヌルは無料です。このツヌルの詳现ずダりンロヌドに぀いおは、公匏りェブサむトwww.microsoft.com/solutionacceleratorsにアクセスしおください。



おわりに



最適レベルのパフォヌマンスを実珟するために、ホストず仮想マシン自䜓を調敎するこずに぀いおいく぀かの掚奚事項を瀺したした。この情報が誰かにずっお圹立぀こずを願っおいたす。



All Articles