今、ネットワークでメールをやり取りして、お互いのファイルを共有して、オフィスに1台しかない高速プリンタをネットワークで使うということは当たり前な世界です。しかし20数年前、このような使い方を「当たり前」と考える文化はありませんでした。病欠の届けは朝の始業前に電話で、伝達事項は全て朝礼で、作業の指示は全て口頭でした。
当時誰が今の様なビジネスのフローを予測したでしょうか。 仮想化は当たり前な技術 システムをベアメタル(物理ハードウェア)で動かす時代はもう終わっています。物理ハードウェアはハイパーバイザーを動かすためにあり、システムはその上で仮想化して動かすのが当たり前な時代です。現代ではベアメタルのハードウェアにインストールするものは、ハイパーバイザーと必要なドライバ、あればハードウェアのリモート管理ツール程度です。 仮想化って遅くない?
場合によっては遅く感じる場合があります。特に Windows8 で標準搭載された Hyper-V から入門した場合はそう思うケースが多いでしょう。 しかし、XEN にせよ KVM にせよ、Linux上で動作する仮想システムは、ほぼベアメタルに近いパフォーマンスを出します。現在では、Windows Hyper-V 以外のハイパーバイザーは、ほぼベアメタルに近い性能が引き出せるように設計されています。 もっとも、利用する周辺機器、例えばストレージネットワーク用のHBAカードなどの都合で、性能を出すためにベアメタルをそのままシステムとして利用するケースも少なくはありません。 実際には一つのシステムで CPUや I/O の性能を100%使い切ることはありません。ほとんどオフィスで使用されるシステムリソースの90%はアイドリングなのです。メモリやCPUコアは2の倍数で増えますから2Gのメモリで微妙にたりなければ4G、8G、16Gと増やしていきます。実際にそれほど使わなくてもです。メモリは3.2Gでいいとか、HDDは20Gもあればいい、というシステムは数多くありますが、実際にはそれ以上のハードウェアを購入して使わざるを得ません。 実際、仮想化システムの一つ、VDIを導入したお客様では、ベアメタルの Windows 7 クライアントより、何十台も動作している仮想サーバー上の Windows 7 クライアントの方が速くて快適に利用しており、この選択は大成功だったそうです。 CPUの性能は年々向上しています。クロックは変わりませんが、搭載するコア数が増えているのです。わざわざ、低価格のCPU、サーバーを導入する手間よりも、ミドルクラスのサーバーに仮想集約した方が、消費電力やディスク、メモリの利用効率は上がります。 特にアプリケーションによっては2スレッド以上ではパフォーマンスが出ないアプリケーションでも、仮想化により2スレッド、4仮想化した場合では、実質4倍の性能が出る場合があります。勿論上限はありますが、一概に仮想化すると遅くなるということはありません。 PR 再起動がムチャクチャ速い ベアメタルのサーバーシステムを再起動してみましょう。電源投入後、真っ暗な画面が30秒ほど続き、見たくもないハードメーカのロゴを見た後。一般的なサーバー専用ハードウェアであれば、BIOSのチェックから接続された NIC やリモート管理システム、RAIDコントローラのチェックが入ってソフトウェアが起動します。まず大体4、5分ですね。イライラします。 しかし、ハイパーバイザーの上で動作する仮想化システムは最初のハードウェアのチェックが省略されるため、非常に起動が速いのです。一般的なサーバーハードウェアで軽量な Linux システムを再起動した場合、わずか30秒程度でシャットダウン、再起動してしまいます。 また、必要最低限のハードディスクの記憶容量を使う場合、DNS/DHCP程度の Linux であれば4Gもあれば十分、Windowsでも20Gもあればシステムが起動でき、必要に応じてネットワーク上のストレージと連携させれば十分に動作します。 仮想環境では、例えば「3.2Gの Windows7/32 のメモリで25GバイトのC:ドライブ」と言ったハードウェアの制限とは関係なく構成を簡単に作り出すことができるのです。 障害時の切り分けが容易 ベアメタルのハードウェアで直接動かした場合、システムダウンの原因がハードウェアにあるのか、OSにあるのか、アプリケーションにあるのかの切り分けが容易ではありません。仮想化環境で、仮想マシンがダウンした場合、多くの場合、仮想マシンそのものの問題です。おそらく別な筐体で動かしても同じ現象が出る可能性が高いのです。 一方、ハイパーバイザーそのものがダウンした場合、ハイパーバイザーの問題か、ハードウェアの問題です。私の経験では、ハードウェア本体の障害を除けば、ハイパーバイザーが原因でシステムダウンを見た経験はありませんので、大抵の場合は、ハードウェアの障害や仮想マシンの詰めすぎが原因です。 もし、空きのハードウェアプールがあれば、仮想マシンを別筐体で動かしてみればいい。それで問題がなくなれば、ハードウェアが原因だという事になります。 移行が簡単 ベアメタルの物理サーバーを新しいサーバーに更新する場合、まず、サーバーを調達するための見積もりや稟議を通して納品されます。次に必要なデータやレジストリのバックアップを取り、新しい物理サーバーをインストールし、デバイスドライバをチューニングして、果てしなく時間がかかる Windows Update をして、データのリストア、アプリケーションの再設定を行います。当然、古いシステムが新しいハードウェアで動作するという保障もありません。オペレーティングシステム自体を買い替える必要もあります。動作検証に恐ろしく時間が掛かります。 たぶん物理>物理のマイグレーション(移植)作業は数週間から数か月の計画が必要です。 仮想化されたシステムを新しい革袋に移し替える場合、単に仮想化されたシステムをコピーして起動し直すだけです。既に当たっているアップデートもそのまま引き継がれるため、単純な移行だけでもコピーに必要な時間だけで新しいハードウェアに移行できるのです。 Windowsであれば、Sysprep したコンピュータイメージファイルを起動して、必要なライセンスを(必要に応じて)設定して、Windows Update すれば、即時にリモートデスクトップ環境を構築できます。かかる時間は僅か30分。 OEMライセンスでなければ、「どこかのPCで仮想マシンを作って」そのディスクイメージを本番環境にコピーするだけで必要なコンピュータ資源が利用できるようになります。 Webサイトを構築する事業者であれば、社内でデザインとPHPとMySQLのプログラミングを完成させて、完成したイメージを納品すれば、お終いです。わざわざ顧客先のコンピュータ室の過酷な環境(低温でウルサく、すわり心地の悪い椅子)で開発せず、ゆっくり自分のオフィスでゆっくりコーヒーを飲みながら集中して開発した、あなたの「製品」を仮想環境に実装して納品完了です。しかも開発環境が手元にあるという事は、ソフトウェアのメンテナンス、改良、チューニング、他の顧客への部品の再利用ができます。 顧客としては、仮想化は発注先に「値引き交渉」をするための重要なインフラになります。 システム全体のバックアップ システムの設定は面倒で、システムのクラッシュを予測してのバックアップとリストアは、運用者にとって悪夢の一つでした。 システムディスクが損失すると、ディスクを交換し、初期化、パッチ当て、リカバリ用のソフトウェアのインストール、テープのスキャン、そしていよいよバックアップからのリストアです。 仮想化システムの場合、システムイメージファイル1つをバックアップしておけば、修理したハードウェアでも、代替の機材であってもイメージファイルをコピーして起動してしまえばそれでお終いです。勿論「代車」から「本番機」に戻す場合も「代車」上のイメージを元に戻せば、最新の環境で利用を継続できるのです。ディザスタリカバリにもBCPにも仮想化は今や当たり前のシステムなのです。 ここに4台の物理ハードウェアのシステムがあるとすれば 当然、それぞれのハードウェアにはメモリもあれば、ディスクもある。おそらくUPSもついていて、コンセントは4つ使われている。ラックに搭載している場合もあれば、PCデスクに積んでいる場合もあるでしょう。KVMスイッチなどを使ってモニタを切り替えて運用し、それぞれのバックアップ対策も面倒で良くわからない。 だから業者に全部お任せ。業者は当然管理者パスワードを知っているから、どのような作業をしているのかは全く分からない。テープドライブも何種類もあり、実際どのように使われているのは、実は良くわかっていない。4台あるため、年に大体1台はリースや保障が切れるため、リプレースします。その計画は何か月もかけて準備したものです。 これが、中小事業者のシステムの実情ではないでしょうか。 最初の第一歩だけなのです。この4台のサーバーを一台のハイパーバイザーに実装すれば良いのです。 最初の一歩 ネットワークケーブルは1本。電源ケーブルも1本。ハードウェアの24時間4H対応のサポートは一つだけ。一つのハイパーバイザーにはネットワークを管理するDNSやDHCP、これは僅か368Mbのメモリで動作しています。 一方でアンチウィルスのパターン配信サーバー、データベースサイズは僅か10G程度ですから、これは丸ごと深夜にシャットダウンとバックアップが行われます。 ファイルサーバーはもう少し面倒でしょう。2Gバイトのメモリを持つ予備のドメインコントローラはユーザ情報とパスワードを、マシン丸ごとでバックアップされます。 他に、プリントサーバーであるとか、電子メールのスキャナーであるとか、様々な機能が1台のハードウェアで動作するのです。 また、××をインストールしたら○○が動かなくなった。という症状は、ソフトウェアの競合が発生しないため、まず発生しなくなります。 このお客様にソフトウェアを開発して納入している業者さんは、自社内で開発してアプライアンス化した「システム」のディスクイメージをUSBのハードディスクなどで納品して、仮想マシンに実装するだけです。 仮想化の最大のデメリットって何? それは、一つのハードウェア資源を複数の部門、予算で運用されることです。比較的小規模なネットワークでは、トップダウンで予算、利用者、運用をひとまとめにできるため、早期導入できます。 しかし、ダンパー数を超えたあたりから、一つの資源を独立した複数の部門で利用するという同意を部門間で得にくくなってきます。例えば、経理が購入したハードウェアに、生産部門のシステムが載ってしまう、という事態は避けたいと考える部門担当者がいます。 これは実際の「大人の事情」です。中々外部からは見えにくい状況です。本来であれば、システム部門が中心となって、コストの安いリソースをトップダウンで共有できる体制を作り上げるのが理想なのです。中々そうも行かないのが現実の問題でしょう。 こういった事情は、構内ネットワーク導入の初期にもよく見られた傾向です。部署ごとに異なるアドレス体系を導入したり、メールアドレスが、myname@mailserver.mydept.mydiv.mybigcorp.com というような、部門による勝手メールサーバーの乱立による一意のメールアドレスではなかったりという巨大企業は日本ではよくありました。 そこでついつい、システム管理担当者は「ネットワークインフラだけに責任を持つ」という低いレベルの業務しか担当したがらなくなります。技術も業務の知識があっても残念なことです。 その後、メールアドレスなどはネーミングスタンダード(命名規則)によって管理されることが多くなりました。同様の管理手段がシステム担当者、システム担当役員にとっても大切な決定事項となります。 作りすぎる仮想マシン あまりにも、システムの仮想化が便利だと、違う意味で困った問題が出てきます。仮想マシンの作りすぎです。ネットワーク管理サーバーから、小さなサービス専用のサーバー、ネットワーク管理用アプライアンス。自由な発想で作った仮想マシンが役に立つとそれは結構なことです。 余計なお世話と言われそうですが、作りすぎた仮想マシンを管理することもまた重荷になります。特に、サーバーとサーバーが連携するようなシステムとした場合、一つの仮想システムの障害が別なサービスに影響を与えるようだと本末転倒と言えます。 システムはシンプルが一番。シンプルなシステムほど、問題は起こりにくいのです。 SUSE Linux ってあんまりよく知らない ドイツで生まれた SUSE Linux は商用 Linux では3割ほどのシェアがあります。特に Linux が生まれ育った東欧、北欧EU諸国の非英語圏での利用者が多いので、英語以外のもっとも多くの言語で利用されている商用 Linux と言えます。EU諸国は何かと米国製品を避けたいけれど、仕方なく使っている、という気風があるせいか、SUSE はヨーロッパ各国で人気のディストリビューションです。 Google Trends によると、SUSE はEU各地で使われ、RedHat は日本と韓国、香港、中国などの東アジアで大きな人気があるようです。RedHat はアメリカ生まれなのですが、この数年は米国国内では SUSE と人気を二分しているようです。 SUSE の "E" は Enterprise の "E" です。元来が企業向けにチューニングされているため SAP を始めとする高度なアプリケーションエンジンとして利用されてきた、高い安定性と実績があります。 Novell が買収した後、SUSE Linux は、元来、政府機関や大企業向けディレクトリ、ID管理用システムのサポートを得意とする Novell Inc. の顧客層にも受け入れられ、その勢いは RedHat を凌ぐ勢いです。 日本語の情報が少ないのは事実ですが、HPやDell, IBM と言った海外メーカーのサーバーではまず確実にサポートされています。インストールからトラブルがあるような心配はまずありません。 トラブルがあるとすれば、それは Linux そのもののトラブルです。こういった情報は他のディストリビューションでも英語でしか見つからないケースがほとんどなのです。 SUSE Linux を仮想化ベースとするメリットとは 何よりも Windows との親和性の高さは大きなポイントです。ご存じのとおり、SUSE は Novell に所有されていた時代に、Microsoft との提携しました。相互運用面で、お互いのシステムを緊密に連携できるようにチューニングされています。この提携は Attachmate グループの SUSE 部門でも有効に機能しています。例えば Hyper-V 上に SUSE Linux をインストールしてみると、自動的に Hyper-V 用のドライバが組み込まれます。このような機能は他のディストリビューションにはありません。 他のLinuxディストリビューションで充分パフォーマンスが出ないことがあっても、 SUSE Linux Enterprise Server (SLES11) と Windows の相性は非常によく、相互にサポート体制が出来上がっています。SUSE では Microsoft 用の準仮想化ドライバを提供しており、XEN でも KVM でも最適なパフォーマンスで動作する環境が用意されます。 XENの「準仮想化:高速」「完全仮想化:パフォーマンスに難あり」と言った、10年前の比較記事が良く見られますが、ハードウェア側のVT技術の進歩により、QEMU を共通基盤とする XEN完全仮想化、KVM共にそれほどパフォーマンスに違いが出なくなりました。ですからITメディア系の記事にもなりません。古い常識はそろそろ削除すべきでしょう。 SUSE (SLES11) + XEN で Windows を動かした場合、仮想化システムとして最高のパフォーマンスを引き出します。 SUSE は難しくないの? SUSE (SLES11) には yast, yast2 という恐ろしく便利なツールが付いています。コマンドを覚えなくとも "yast" とプロンプトから打ち込めば、ネットワークの設定からアプリケーションのインストール、パーティションの作成、基本的なサーバー機能の設定を全て、メニュー形式で行えます。 ![]() CUIコンソールで yast を使ってサービスをメンテナンス ![]() yast2 によるパーティション管理 何しろ、綴りを知らなくても操作ができる。 他のディストリビューションと違い、手元にハンドブックと電卓を持ち歩いて、正確なコマンドラインを打ち込むことなく、必要な設定を行う事ができるのです。 SUSE Linux をハイパーバイザーとした場合、実際にハイパーバイザーを操作する作業は、まずありません。まず、大きなトラブルがないため、Windows のように、アッチの設定を変え、コッチの設定を変え、そして動かなくなる、という運用にはならないからです。 精々、仮想マシンの再起動やシステム全体をシャットダウン、リブートする操作程度は覚えておくべきです。 ハイパーバイザーで Login: のプロンプトしか出ていない状態で、その中にいくつもの Linux や Windows のシステムが動いている。この事態は、ちょっと想像もできないし、感動ものです。 私はそう思いました。 Linux のコンソールは操作するものですか 物理ハードウェアの Linux コンソールを操作することはほとんどありません。まず、物理的な障害で、電源再投入時にハードウェアのエラーがあるときや、ネットワークの初期設定に使用するだけです。ここまでは、ほとんどが顧客の作業ではなくメンテナンス業者が行う作業です。 ネットワークの接続に問題がなければ、後の操作はほとんど Windows からリモートで行います。 シャットダウンと再起動でさえ、ほとんどリモート操作で行います。 Windowsからの操作は CUI のテキスト端末なら Putty や TeraTerm などのフリーウェア、GUIの操作なら Xming や Mobaterm などの X サーバーをインストールして操作します。物理的に、サーバーを鍵のかかる部屋に押し込めて、決まった端末からだけリモートアクセスできるようにして、セキュリティ上のトラブルを避けることができます。 仮想マシンの操作はどうやってやるの? ほとんどの仮想マシンの操作は、Linux/Unix 系の場合 Putty とか TeraTerm のようなテキストエミュレータで行います。GUIが必要な場合は Xming などの X サーバーソフトウェアから操作します。 仮想マシンが Windows の場合は、リモートデスクトップです。実際に通信で流れるのはが画面の情報だけなので、非常に軽快に動作していることを実感できるでしょう。 実際の仮想マシンの「生のコンソール」を見たい場合は、ホストコンピュータに X サーバーソフトウェアで接続して、仮想マシン管理ツールを起動すれば、「生の仮想マシン」のコンソールを直接呼び出すことができます。若干使いづらいケースが多いので、あまり使う事はありません。 ![]() 実際の操作は X サーバーか、リモートデスクトップ、リモートターミナルで行います。 精々、ネットワークの初期設定や、リモートデスクトップを有効化したら、あとは使う場合は問題が起きた場合だけでしょう。 従来のベアメタルハードウェエアを並べていた場合は、キーボードの切替機(KVMスイッチ)を使って切り替えて使っていましたが、リモートで操作する場合は、いくつものサーバーの画面をソフトウェアで切り替えて使う事ができます。 ハイパーバイザーは高価? 「仮想化は初期導入コストが高い」 と考える人が多いことは残念です。初期導入コスト以上のメリットが中々伝わらないのは、「仮想化=Hyper-V」と考えた場合です。 確かに「ハイパーバイザーだけ」の VMware や Hyper-V を使おうとすると費用はとんでもない価格になります。ハイパーバイザー自体が無料でも管理用のソフトウェアのライセンス料が高いのです。 Windows Server の Hyper-V の機能を使う場合は、アンチウィルスソフトウェアも必要です。大抵はサーバー版のライセンスですから一般的に高価になるかもしれません。Windows でアンチウィルスソフトウェアがない状態で運用するのは、冬の札幌ススキノの街を皮底の靴で歩くようなもので、気を付ければ転ばなくても、ちょっと気を抜けば転ぶでしょう。 SUSE Linux (SLES11) は普通の商用 Linux で、最低料金は年間4万1千円から無制限インスタンスで利用できます。しかもオープンソースである以上、購入するのはあくまでもサポートだけです。XEN も KVM もこの費用に含まれる、言わば「オマケ」に過ぎません。 一方 Windows Datacenter Edition は117万円もします。頻繁な Windows Update やアンチウィルスによる再起動が必要な事を考えると、実際には二重化することになります。つまり117万円×2の費用と2台分のハードウェアが必要です。 Windows8 の Hyper-V で「仮想化はお手軽だ」と思った方はいいセンスをしています。そこで Hyper-V を選ぶという理由にはならないでしょう。 本当の仮想化システムは Windows の Hyper-V で味わえるような「お手軽」で「重い」システムではないのです。 SUSE Linux (SLES11) で仮想化する場合はそんな冗長なコストをかける必要はありません。 また SUSE Linux Enterprise Server は入手のしやすさも特徴です。まず、登録だけで無料でインストールしてテストでき、サポートサブスクリプションを後に購入することができます。まさにオープンソースです。 XEN か KVM か SUSE Linux は XEN も KVM も標準です。KVM は Linuxの x86 専用ですが、XEN はLinux だけではなく BSD から Soralis また PowerPC や IBM のzシリーズまで広く使われています。i386 時代から実績があるため Google を始め多くの ISP, ASP で使われています。 RedHat EL では KVM のみサポートされています。Linux だけではなく BSD や Windows などを動作させるには一工夫が必要です。 ただ、KVMは、「今一番ホットな」仮想化手段で Linux とインテルアキテクチャの世界だけであればお手軽です。日本では人気があります。完全仮想化でIOをQEMU でエミュレーションします。 XENを選ぶかKVMを選ぶかは単に好みの問題かもしれません。ちょっと面倒だけど堅牢で様々なプラットフォームで動作し、実績も高く、高速なXENか、手軽で流行りのKVMか。 SUSE Linux Enterprise Server (SLES11)の x86-64版は両方をサポートしています。 止めた方がいいと一応、申し上げます。フリーの Linux は自己責任で使うものです。システムに襲われた被害は全てあなたの責任です。 例えば SUSE Linux のフリー版 openSUSE のサポート期間は僅か14か月。出荷直後はバグも多く、一般的には安定していません。解決するための長い時間がコストとして跳ね返ってくるでしょう。 ただし、自己責任で色々なトレーニングや、最新の周辺機器、デスクトップアプリケーションを使うだけと言った目的であれば、有効な選択です。 CentOS のような長いサポートを提供するフリーLinuxもありますが、やはり、業務で使うには使う側に十分な責任感が求められます。 Linuxのハイパーバイザーにウィルスソフトは必要ですか 必要ないと考えています。 攻撃は 1) 脆弱性があり、2) 攻撃用の設定を行う 3) 実際の攻撃を実行する。の3段階があります。 Windows サーバーの場合、1) IE やフラッシュの脆弱性を使い > Windows Update を行う 2) 実際にコードを埋め込み > ウィルススキャンで防御 3) 何らかのタイミングでアタックを開始する。> ファイアウォールが許可される。 という手順で行われます。しかし Linux は 1) の脆弱性自体が公開されているケースが多く、 1) の段階でほとんどのセキュリティホールがふさがれます。 2) の段階では、Linux は x フラグ(実行フラグ)を設定する必要があったり、実際のプログラムにトロイの木馬入りのプログラムに差し替えなければならないので攻撃は困難です。 3) のアタック開始は、実際にオペレータが操作しなければなりません。 100%の安全は保障できないにせよ、Windows よりはるかに面倒な攻撃をおこなわなければならないのです。 また Linux はディストリビューションによって、ソフトウェアの実装方法が違うため「下手な鉄砲数打ちきゃ当たる」的な攻撃はまず通用しません。 攻撃する側はじっくり腰を据えて、「標的型のアタック」を行う必要があるのです。
by islandcenter
| 2014-07-12 07:18
| プライベートクラウド
|
Comments(2)
> SUSE の "E" は Enterprise の "E" です。
元々はドイツ語のSoftware- und System-Entwicklungの頭文字だったんですが……、Micro Focusの子会社となって変わっちゃったんでしょうか……?
0
Enterprise のドイツ語が分からなかったので...補完すみません。MicroforcusもAttachmate もほとんど資本組合みたいなものですから、あくまでも「ブランドを管理している同じグループ企業」という事だと思います。実際 suse.com をホスティングしているサーバーは Novell Inc. なので、あまり変わらないでしょうね。
|
by isLandcenter 記事ランキング
最新の記事
カテゴリ
全体
OES Linux Native Netware GroupWise Windows SUSE Novell ZENworks XEN Identity Management プライベートクラウド Windows 8 OES2 Linux/NetWare Windows 7 KVM MacOS 雑文 Linux Internet Windows11 Cloud システム管理 Apple Gadget 未分類 タグ
HowTo(236)
Linux(223) SUSE(190) システム管理(165) Windows(94) 仮想化(80) 比較(61) Windows10(46) Mac(40) Network(34) Windows11(34) 止める(22) Novell(20) zabbix(18) OES(16) IT ビジネス(16) Cloud(9) ZENworks(9) Squid(6) WSUS(5) 以前の記事
2027年 12月
2026年 03月 2026年 02月 2026年 01月 2025年 12月 2025年 11月 2025年 10月 2025年 09月 2025年 06月 2025年 05月 2025年 03月 2025年 02月 2025年 01月 2024年 12月 2024年 11月 2024年 10月 2024年 09月 2024年 05月 2024年 04月 2024年 03月 2024年 02月 2024年 01月 2023年 12月 2023年 11月 2023年 10月 2023年 09月 2023年 08月 2023年 07月 2023年 06月 2023年 05月 2023年 04月 2023年 03月 2023年 02月 2023年 01月 2022年 12月 2022年 11月 2022年 10月 2022年 09月 2022年 08月 2022年 07月 2022年 06月 2022年 05月 2022年 04月 2022年 03月 2022年 02月 2022年 01月 2021年 12月 2021年 11月 2021年 10月 2021年 09月 2021年 08月 2021年 07月 2021年 06月 2021年 05月 2021年 04月 2021年 03月 2021年 02月 2021年 01月 2020年 12月 2020年 11月 2020年 10月 2020年 09月 2020年 08月 2020年 07月 2020年 06月 2020年 05月 2020年 04月 2020年 02月 2020年 01月 2019年 12月 2019年 11月 2019年 10月 2019年 09月 2019年 08月 2019年 07月 2019年 06月 2019年 05月 2019年 04月 2019年 02月 2018年 12月 2018年 11月 2018年 10月 2018年 09月 2018年 08月 2018年 07月 2018年 06月 2018年 05月 2018年 04月 2018年 03月 2018年 01月 2017年 12月 2017年 11月 2017年 10月 2017年 09月 2017年 08月 2017年 07月 2017年 06月 2017年 05月 2017年 04月 2016年 10月 2016年 08月 2016年 07月 2016年 06月 2016年 05月 2016年 04月 2016年 03月 2016年 02月 2016年 01月 2015年 12月 2015年 11月 2015年 10月 2015年 08月 2015年 07月 2015年 06月 2015年 05月 2015年 04月 2015年 03月 2015年 02月 2015年 01月 2014年 12月 2014年 11月 2014年 10月 2014年 09月 2014年 08月 2014年 07月 2014年 06月 2014年 05月 2014年 04月 2014年 03月 2014年 02月 2013年 12月 2013年 11月 2013年 10月 2013年 09月 2013年 08月 2013年 07月 2013年 06月 2013年 05月 2013年 04月 2013年 03月 2013年 02月 2013年 01月 2012年 12月 2012年 11月 2012年 10月 2012年 09月 2012年 08月 2012年 07月 2012年 06月 2012年 05月 2012年 04月 2012年 03月 2012年 02月 2012年 01月 2011年 12月 2011年 11月 2011年 10月 2011年 09月 2011年 08月 2011年 07月 2011年 06月 2011年 05月 2011年 04月 2011年 03月 2011年 02月 2011年 01月 2010年 12月 2010年 11月 2010年 10月 2010年 09月 2010年 08月 2010年 07月 2010年 06月 2010年 05月 2010年 04月 2010年 03月 2010年 02月 2010年 01月 2009年 12月 2009年 11月 2009年 10月 2009年 09月 2009年 08月 2009年 07月 2009年 06月 2009年 05月 2009年 04月 2009年 03月 2009年 02月 2009年 01月 2008年 12月 2008年 11月 2008年 10月 2008年 09月 2008年 08月 2008年 07月 2008年 06月 2008年 05月 2008年 04月 2008年 03月 2008年 02月 2008年 01月 2007年 12月 2007年 11月 2007年 10月 2007年 09月 2007年 08月 2007年 07月 2007年 06月 2007年 05月 2007年 04月 2007年 03月 2007年 02月 2007年 01月 2006年 12月 2006年 11月 2006年 10月 2006年 09月 2006年 08月 2006年 07月 2006年 06月 2006年 05月 2006年 04月 2006年 03月 2006年 02月 2006年 01月 2005年 08月 Hot Hot!
PR
検索
最新のコメント
ブログジャンル
|
ファン申請 |
||