HrsTのあれこれ: 5月 2019

ブログ記事でIPアドレスを扱うとき・・・

前の投稿でIPアドレスを書いたんだけど、
はじめはClassAの10.0.0.1って書いたんだよね。
で、読み直したら、IPアドレスに触れない人にとって、IPアドレスって認識してもらえないかも？とおもったので、ClassCの192.168.0.1に書き換えた。

家庭用ルーターの多くは192.168.1.1が初期値に設定してあるし、192.168って続けばIPアドレスか～って直感的に読んでくれるとありがたいと思った。

個人的には、利用者パソコンとかを接続するセグメントはClassAで読みやすく、
バックボーンはClassBにしたい。

ClassCは家庭用ルータをはじめ、IPアドレスが設定されている謎の企業向け機器などの初期値として使われているので利用は避けている。

ClassAのどこがいいって、10.<拠点番号>.<フロア番号>.<ノード>って区切り良く表現できるとこだよ。まぁ、255拠点以上あって255階以上高層ビルを持つ大企業には無理だけど、たいていの企業はこれで十分なんだよなぁ～

もうIPv4は枯渇してていまさら何言ってんだ？とか言われそうだけど、
IPv6の企業内利用のセオリーなんてまだ聞いたことないぞ。
聞こえてこない。

オンプレミスSharePoint Serverのバージョンアップに備える5 まとめ

なんとなくシリーズ化させて書いていますが、簡潔にまとめます。
文字が増えると間違いも増えるので注意が必要だ。

パスベースのサイトコレクションが増えるとバージョンアップで確実に困る。
ホスト名付きサイトコレクションなら何とかなる。

ホスト名付きサイトコレクションだ！！

と個人的には思ってます。
少なくとも私はホスト名付きサイトコレクションに救われました。
ぜーんぶホスト名付きサイトコレクションにしたら多分不幸になるのでやりすぎは注意。

オンプレミスSharePoint Serverのバージョンアップに備える4

ところで・・・

構成A
http://contoso/sites/TeamA

http://contoso/sites/TeamB

http://contoso/sites/TeamC

http://contoso/sites/TeamD

http://contoso/sites/TeamE

構成B
http://TeamA.contoso/

http://TeamB.contoso/

http://TeamC.contoso/

http://TeamD.contoso/

http://TeamE.contoso/

構築が簡単なのはどっち？
答えは構成A

サイトコレクションを作成するとき楽なのはどっち？
答えは構成A

ユーザーにサイトコレクションを自由に作成させたい。楽なのはどっち？
答えは構成A

バージョンアップするときに楽なのはどっち？
答えは構成A。

バージョンアップ中の更新禁止時間が長いのはどっち？
答えは構成B（たぶん）

毎週土曜日に、一つずつバージョンアップすることができるのはどっち？
答えは構成B（たぶん）

答えが構成Bのとき「たぶん」ってあるけどなんで？
「できるよ」っていうSharePoint神がいたとき対策。
異なるSharePointバージョンで同じホスト名を使って運用する方法を知らないんだ。

バージョン混在でも全く疑問を感じない構成Bがおすすめってこと。

http://TeamA.contoso/　192.168.0.1　SharePoint2007

http://TeamB.contoso/　192.168.0.2　SharePoint2010

http://TeamC.contoso/　192.168.0.3　SharePoint2013

http://TeamD.contoso/　192.168.0.4　SharePoint2016

http://TeamE.contoso/　192.168.0.5　SharePoint2019

大事なことは、「ホスト名付きサイトコレクションは知らないと損」
だまされたと思って調べてね。損はない。いや、知らないことが損。

オンプレミスSharePoint Serverのバージョンアップに備える3

コンテンツデータベース内のサイトコレクション数っていくつが良いの？
　偉い人教えて～～～

個人的な意見ですが、どんなに詰め込んでもよいのでは？と思ってます。
とはいえ、100GBを超えないようにするのが良いようです。
100GBに近づいてきたら Move-SPSiteで一部のサイトコレクションを別のコンテンツデータベースに移動させることをお勧めします。

もし、一つのサイトコレクションのサイズが100GBを超えそうな状態なら、それ以上サイズが増えないように、何かを頑張ってください。

URLが変わってもよいという協力的なユーザーに恵まれているなら、Export-SPWeb, Import-SPWebでサブサイトを別のサイトコレクションにコピーして、サイズを減らしましょう。

とりあえず、運用中は1対1がベストだし、バージョンアップ時は、コンテンツデータベースが少ないほうが楽。だと思う。

オンプレミスSharePoint Serverのバージョンアップに備える2

データベース接続方式って素晴らしいよ。

SharePointのサイトコレクションはコンテンツデータベースに保存されていて、サーバー構成情報とは分離しているので、このサイトコレクションで新バージョンや検証サーバーしたいと思ったら、該当のコンテンツデータベースのバックアップを作成し、新環境のデータベースにリカバリして接続すれば、サーバー名が異なっても問題なく動作する。
サーバー名が異なるのでリンク切れとか発生する場合もあるけど、普通に動作する。

サイトコレクションの変更はすべてコンテンツデータベースに保存されるので、やり直したいときも、コンテンツデータベースを差し替えるだけでよい。

いろいろ試したいなぁと思ったときにすぐできるのが非常に良い。

（ノーツなら掲示板の設計とコンテンツが分離されていて、デザイン変更も安心だぜ！！なんて思っている人にとっては物足りないけどね～）

気軽にいろいろできるデータベース接続方式だけど、ちょっと考えないといけない点がある。

1つのサイトコレクションは、複数のコンテンツデータベースにまたいで保存することはできない。
一つのコンテンツデータベースには、複数のサイトコレクションを含むことができる。

運用中はあまり気にしなくてもいいんだけど、データベース接続方式って言葉を聞く段階では大きな問題になってることもあるから注意が必要。

例えば、一つのサイトコレクションの作業をしたいのに、1000個のサイトコレクションが同じ一つのコンテンツデータベースに保存されているとき。

別のサーバーで使うにはコンテンツデータベースのコピーを使うので、一つしかいらないのに不要な999個のサイトコレクションもおまけについてくるんだ。

データベースを接続する際には、チェックとかアップグレード処理が動くので、999個分の無駄な処理が動き、当然待ち時間も増えてしまう。

だから、一つのコンテンツデータベースには一つのサイトコレクションが無駄がなくてよいよね。

でも、全部バージョンアップするときは、1000個のコンテンツデータベースのバックアップを取って、接続してって処理が必要になるので、多すぎるのも面倒。1個のコンテンツデータベースのほうが接続時の処理が1度に終わるので、実質こっちのほうが時間は短いのかな？どうなんだろうね。

オンプレミスSharePoint Serverのバージョンアップに備える１

もう経験した？いまだに2007使ってる？
準備は大変だし、待ち時間ながいし、停止時間長いと怒られるし・・・

私はWSS3.0から使い始めて、今は2016だよ。
うん、頑張った。
WSS3.0から2016にバージョンアップした際は、なんて無茶するんだろう？なんて思ったし、スキップしちゃだめだとかその時は思ったけど、結局2010から2016に2013スキップしちゃう自分がいる。実は2019まで行っちゃおうか？なんて本気で考えていたけどね。（さすがにMicrosoft Docsで日本語翻訳されていないタイミングは早すぎると）
正直に言うと2013は運用したことない。あれは2016への通過点だから動けばよかった・・・2010から2013にバージョンアップして何が変わるか細かくは知らないんだよね・・・通過点だからどうでもよかったし～

SharePointのバージョンアップってテータベース接続方式だから、スキップしたとしてもそんなに難易度が上がるってことはなくて、単純に作業量が一気に来るだけなんだよね～
WSS3.0からだと、コンテンツデータベースをSharePoint2010に接続して切断、つぎに2013に接続して切断、さらに2016に接続するだけで作業が終わる。途中のバージョンに合わせて修正する必要がないのでトータル的には作業量は少なく済む。複雑なことしてなければほんと簡単なんだよなぁ～

はっきりいって、メンテナンス中のコンテンツ更新禁止時間に文句が出なければバージョンアップしない理由なんてない。
作業を始めたら終わるまでコンテンツ更新できないんだよね～

だから、とりあえず、テスト環境でバージョンアップ時間を計って、許容範囲か確認したらよいと思うよ。

登録: 投稿 (Atom)