متى يجب أن يؤثر صيانة الخادم على أرجيات التنفيذ؟

Question

ها هي وضعي ...

أنا أكتب نظام أمان .NET / C # (إذن ومصادقة) للحصول على مجموعة كبيرة من تطبيقات الويب التي تتطلب عملية تسجيل الدخول واحدة. أنا أستخدم Active Directory كحل بيانات وكتبت نموذجا أوليا لطيفا جدا يتواصل مع الإعلان عبر LDAP. يسترجع هذا المكون معلومات حول المستخدم المسجل الذي قمت بتخزينه في الإعلان الذي استخدمته بعد ذلك لتعيين أدوار الأمان الخاصة بهم في مصادقة نماذج .NET.

1) كل شيء جيد.

عدم كونه مسؤول النظام، أو مهندس شبكة، لم أكن على دراية بمبلغ إدارة النظام المعني بإعداد مثيل إعلاني. لم أكن أدرك أنه لكل مجال، كنت بحاجة إلى خادم منفصل ومراقب المجال. كما اتضح، هناك مثل 9 مجالات مختلفة يتطلب فريقي إعدادها لجميع البيئات المختلفة التي سنقوم بالوصول إلى الإعلان ...

• Env1.dev.mycompany.com.
• Env1.qa.mycompany.com.
• Env1.Stage.mycompany.com.
• Env2.dev.mycompany.com.
• إلخ

... حتى الآن لقد وضعت على نفسي إلى حد نفس من الصداع الإداري لأنني سأضطر إلى الحفاظ على كل هذه الآلات (أو VM)، وهو شيء ما لم أكن متأكدا بالضرورة أريد القيام به.

2) كل شيء ليست جيدة.

النموذج الأولي صلب حقا، ويجعل الإعلان لقاعدة بيانات جيدة جدا للحل، ولكن الآن أتساءل عما إذا كان يجب عليك إلغاء الرمز واكتب مزود بيانات SQL Server بدلا من ذلك (أعرف .NET يوفر بالفعل واحدة، لكنه لا يوفر ذلك 'T وحده يصلح متطلبات العمل الخاصة بي للحصول على إذن).

على أي حال، لذلك أحاول التفكير في هذه المشكلة من منظور رفيع المستوى. بشكل عام، أظل التعثر على حقيقة أنني سأرمي حلا جيدا حقا بسبب بعض صيانة الخادم؟ أنا أتساءل عما إذا كان أي شخص هنا شهد سيناريو مثل هذا وماذا قررت بالضبط.

لا يجب أن تكون محددة للإعلان أيضا، مجرد موقف حيث اضطررت إلى تقييمه بين حل برامج جيد وقيود صيانة الخادم.

Answer 1

بشكل عام، قابلية استخدام المنتج هو ما يجعل الناس يختارون بينها ومنتجات مماثلة. إذا كان للمنتج قابلية استخدام سيئة، فلن يهتم المستخدمون بمدى جودة كودها - كل ما يهم لهم هو مدى سهولة الاستخدام والفعالين هو استخدامها ومدى ملء احتياجاتهم.

يمكن اعتبار الصيانة كجانب واحد من قابلية الاستخدام. أود أن أجعلها أولوية قصوى للحصول على منتج سهل الصياد بسهولة. على المدى الطويل الذي سيوفر عدة ساعات من العمل من المسؤولين.

إحدى طرق التفكير في الأمر، هو أول تصميم ما هو الحل الأكثر قابلية للاستخدام من وجهة نظر المستخدم / المسؤول النهائي، ثم جعلها تحديا فكريا لتنفيذ هذا الحل الأمثل في الواقع. من المحتمل أن تتطلب المزيد من الجهد من المبرمج، لكن النتيجة النهائية ستكون أفضل.

علي سبيل المثال zfs. هو منتج واحد حيث تم الاعتناء بالصيانة بشكل جيد (على الرغم من أنني لم أستخدمه شخصيا). عندما تم تصميمه، تم وضع الكثير من الجهد في جعل من السهل إدارة نظام الملفات مع أدوات سطر الأوامر في ZFS - وتؤثر هذه القرارات على جميع مستويات ZFS (على سبيل المثال تجمعات التخزين).

مثال آخر، كنت تخطط مؤخرا كيفية إجراء الصيانة في مشروع مستقبلي من الألغام - قاعدة بيانات موزعة وخادم التطبيقات. التفكير في كيفية حدوث مهام الإدارة النموذجية (تثبيت / ترقية التطبيقات، إضافة / إزالة الخوادم في الكتلة، حل فشل الأجهزة وما إلى ذلك)، ساعدني في فرز بعض قرارات التصميم. البعض منهم يعيق في بنية النظام (على سبيل المثال كيف يتم تحميل التطبيقات والملحقات في وقت التشغيل، وكيفية العثور على الخوادم خوادم أخرى في الكتلة).

Answer 2

إذا قمت بإعداد علامة واحدة على نظام لنظام Windows، فستكون لأعلى جدا استخدام الإعلان. كشركة SYS. أحاول اتباع سياسة واحدة من مصادر البيانات. يعقد الإعلان بالفعل الكثير من بيانات مستخدم / أمان Windows. أفضل أن يكون هناك كل ما في النظام الثاني بدلا من النظام الثاني.

عند إعداد بيئات DEV / TEST / PROD أحاول التأكد من أن المباراة عن كثب Prod One، الأكثر خصوصا في المنطقة قيد التشغيل (حيث يتم وضع جهود التنمية، إلخ). لذلك إذا قام بإعداد نظام لتطوير واجهة مع إعلان، فمن المحتمل أن يكون لديك خوادم إعلانية متعددة.

ما هي الخيارات التي يمكن أن تبسيط المشرف؟

هل يمكن أن يكون لديك خادم رئيسي واحد تحافظ عليه بالطريقة القياسية واستخدام شيء مثل عملية نسخ VMware للحفاظ على جميع أو معظم الآخرين؟ بدلا من القيام بشيء ما إلى 9 خوادم، احتفظ بالثلاثة الأخرى كنسخة من تلك المرآة سيد باستثناء التغييرات التي تم إجراؤها لدعم DEV / TEST؟

يمكنك تشغيل مجالات ديف أو اختبار متعددة من خادم إعلان واحد؟

هل يمكنك إجراء النصي؟

هل يمكنك تقليل عدد البيئات، خاصة في الطرف الأعلى من الاختبار؟ على سبيل المثال، تقدم بيئات ديف متعددة وإطلاقات الدور في اختبار واحد؟

Answer 3

لماذا لا تستخدم ببساطة ous بدلا من المجالات المنفصلة عند الاختبار؟ هذا هو، لديك مجال واحد، ولكن حدد أن المستخدمين للحصول على إصدارات معينة يجب العثور عليها في OU معين داخل هذا المجال. ما ستفعله هو في وظائف البحث الخاصة بك بحثا عن المستخدمين، فستحدد OU معين كجذر البحث بدلا من جذر المجال. في كل شركة يمكن أن يكون لديك معرفات تدمج البيئة لإبقائها فريدة من نوعها، على سبيل المثال، user_env1_dev, user_env2_dev, user_env1_qa, ...

يمكنني استخدام الإعلان كثيرا لتطبيقاتي وعدم إعداد مجالات منفصلة للتنمية / الاختبار.

Answer 4

استخدم نمط موفر وإجرانة مكالمات مصدر البيانات الخاصة بك.

ثم يمكنك تكوينه لاستخدام الإعلان أو SQL على الطاير.

public abstract SSODataProvider {
     public bool AuthenticateUser(string u, string p);
}

public ADSSODataProvider : SSODataProvider {
    public override AutheticateUser(string u, string p) {
       //do auth here
    }
}

public SQLSSODataProvider : SSODataProvider {
    public override AuthenticateUser(String u, string p) {
      //call DB
    }
}

public static SSODataProvider dataProvider;

if (ConfigurationSettings.AppSettings["SSODataProvider"] == "SQL")
   dataProvider = new SQLSSODataProvider();
else
   dataProvider = new ADSSODataProvider();

....

dataProvider.AuthenticateUser("sss","sss");