서버 유지 보수가 구현 내역에 언제 영향을 주어야합니까?

Question

여기 내 상황은 ...

싱글 사인온 (single sign-on) 프로세스가 필요한 많은 웹 응용 프로그램에 대해 .Net/C# 보안 시스템 (인증 및 인증)을 쓰고 있습니다. Active Directory를 데이터 저장소로 사용 중이며 LDAP를 통해 AD와 통신하는 매우 멋진 프로토 타입을 작성했습니다. 이 구성 요소는 AD에 저장 한 로그인 한 사용자에 대한 정보를 검색 한 다음 AD 양식에 보안 역할을 설정하는 데 사용합니다.

1) 모두 좋다.

시스템 관리자 나 네트워크 엔지니어가 아니기 때문에 AD 인스턴스 설정과 관련된 시스템 관리에 익숙하지 않았습니다. 나는 각 도메인마다 별도의 서버와 도메인 컨트롤러가 필요하다는 것을 알지 못했습니다. 우리가 AD에 액세스 할 수있는 모든 다른 환경에 대해 팀원이 설정해야하는 9 개의 다른 도메인이 있습니다 ...

• env1.dev.mycompany.com
• env1.qa.mycompany.com
• env1.stage.mycompany.com
• env2.dev.mycompany.com
• 는 등

... 그래서 지금은시에 놓여있다 나 자신 왜냐하면 내가이 기계들 (또는 VM들)을 모두 유지해야하기 때문이다. 그것은 내가 반드시하고 싶지 않은 것이기 때문이다.

2) 모두 좋지 않습니다.

프로토 타입은 정말 견고하고 AD는 솔루션을위한 아주 좋은 데이터베이스를 만듭니다. 그러나 이제 코드를 스크랩하고 대신 SQL Server 데이터 공급자를 작성해야하는지 궁금합니다 .Net이 이미 제공하고 있습니다. ,하지만 인증만으로는 비즈니스 요구 사항에 맞지 않습니다.

어쨌든이 문제를 높은 수준의 관점에서 생각하려고합니다. 일반적으로 서버 유지 관리 때문에 정말 좋은 솔루션을 던지고 있다는 사실을 계속해서 파악하고 있습니다. 여기있는 사람이 이런 시나리오를 경험하고 정확히 무엇을하기로 결정했는지 궁금합니다.

AD에만 국한되지 않아도 좋은 소프트웨어 솔루션과 서버 유지 관리 제약 사이를 평가해야하는 상황입니다.

Answer 1

일반적으로 제품의 유용성은 사람들이 제품과 유사한 제품을 선택하도록 만드는 것입니다. 제품의 사용성이 좋지 않은 경우 사용자는 코드의 품질이 얼마나 좋은지 신경 쓰지 않을 것입니다. 중요한 것은 사용하기 쉽고 효과적이며 필요한 것을 얼마나 잘 채우고 있는지입니다.

유지 관리는 유용성의 한 측면으로 생각할 수 있습니다. 쉽게 유지 보수 할 수있는 제품을 갖추는 것이 최우선 과제입니다. 장기적으로 관리자들로부터 많은 시간을 절약 할 수 있습니다.

한 가지 방법은 처음에는 최종 사용자/관리자의 관점에서 가장 유용한 솔루션을 설계 한 다음 실제로 최적의 솔루션을 구현하는 것을 지능적으로 어렵게 만드는 것입니다. 아마도 프로그래머의 노력이 더 필요할 것이지만 최종 결과가 더 좋을 것입니다.

예를 들어 ZFS은 유지 관리가 잘 처리 된 제품 중 하나입니다 (개인적으로 사용하지는 않았지만). ZFS의 명령 줄 도구를 사용하여 파일 시스템을 쉽게 관리 할 수 ​​있도록 많은 노력을 기울였습니다. 이러한 설계 결정은 모든 수준의 ZFS (예 : 저장소 풀)에 영향을줍니다.

또 다른 예로, 최근에 광산의 미래 프로젝트 (분산 데이터베이스 및 응용 프로그램 서버)에서 유지 관리 방법을 계획했습니다. 일반적인 관리 작업 (응용 프로그램 설치/업그레이드, 클러스터에 서버 추가/제거, 하드웨어 오류 해결 등)이 어떻게 될지 생각하면 설계상의 결정을 내릴 수 있습니다. 그 중 일부는 시스템 아키텍처 (예를 들어 런타임에 응용 프로그램과 확장이로드되는 방식 및 서버가 클러스터의 다른 서버를 찾는 방법과 같은)에 매우 깊이 관여합니다.

Answer 2

Windows 시스템에서 싱글 사인 인 (single sign on) 시스템을 설정하면 AD를 사용하는 것이 좋습니다. 시스템 관리자. 단일 소스 데이터 정책을 따르려고합니다. AD는 이미 내 Windows 사용자/보안 데이터의 대부분을 보유하고 있습니다. 나는 두 번째 시스템보다는 모두 안에있는 것을 선호합니다.

dev/test/prod 환경을 설정할 때 가장 중요한 부분 (특히 개발 작업이 진행되는 곳)에서 Prod 환경과 가장 일치하도록 노력합니다. 그래서 AD와 인터페이스를 개발하기 위해 시스템을 설정한다면 아마도 여러 개의 AD 서버를 가질 것입니다.

어떤 옵션을 사용하면 관리자를 단순화 할 수 있습니까?

표준 방식으로 유지 관리하고 다른 사람의 전부 또는 대부분을 유지 관리하기 위해 VMware 복사 프로세스와 같은 것을 사용하는 마스터 서버가 1 대있을 수 있습니까?9 개의 서버로 작업하는 대신 dev/test를 지원하기 위해 변경된 부분을 제외하고 다른 8 개를 해당 미러의 복사본으로 유지하십시오.

하나의 AD 서버에서 여러 개의 Dev 또는 Test 도메인을 실행할 수 있습니까?

조치를 스크립트 할 수 있습니까?

환경의 수를 줄일 수 있습니까? 특히 테스트의 높은 단계에서 환경을 줄일 수 있습니까? 예 : 하나의 테스트 환경으로 여러 개발 환경과 역할 릴리스를 제공합니까?

Answer 3

테스트 할 때 별도의 도메인 대신 단순히 OU를 사용하지 않는 이유는 무엇입니까? 즉, 단일 도메인을 가지지 만 특정 버전의 사용자를 해당 도메인의 특정 OU에서 찾아야한다고 지정합니다. 사용자를 검색하는 검색 기능을 사용하면 도메인의 루트가 아닌 검색 루트로 특정 OU를 지정할 수 있습니다. 각 OU에서 당신이 user_env1_dev, user_env2_dev, user_env1_qa, ... 예를 들어, 독특한를 유지하는 환경을 통합 ID를 가질 수

내 앱에 광고를 많이 사용 및 개발/테스트를위한 별도의 도메인을 설정하지 않습니다.

Answer 4

공급자 패턴을 사용하고 데이터 소스 호출을 추상화합니다.

그런 다음 AD 또는 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");