서버 유지 관리는 언제 구현 결정에 영향을 미칩니까?

StackOverflow https://stackoverflow.com/questions/779511

문제

제 상황은 이렇습니다...

저는 Single Sign-On 프로세스가 필요한 대규모 웹 응용 프로그램 모음을 위한 .Net/C# 보안 시스템(권한 부여 및 인증)을 작성하고 있습니다.저는 Active Directory를 데이터 저장소로 사용하고 있으며 LDAP를 통해 AD와 통신하는 아주 멋진 프로토타입을 작성했습니다.이 구성 요소는 AD에 저장한 로그인한 사용자에 대한 정보를 검색한 다음 .Net 양식 인증에서 보안 역할을 설정하는 데 사용합니다.

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에만 국한될 필요는 없으며, 좋은 소프트웨어 솔루션과 서버 유지 관리 제약 사항 사이에서 평가해야 하는 상황만 있으면 됩니다.

도움이 되었습니까?

해결책

일반적으로 제품의 유용성은 사람들이 해당 제품과 유사한 제품 중에서 선택하게 만드는 요소입니다.제품의 유용성이 좋지 않으면 사용자는 코드 품질이 얼마나 높은지 신경 쓰지 않을 것입니다. 그들에게 중요한 것은 사용하기가 얼마나 쉽고 효과적인지, 그리고 제품이 자신의 요구 사항을 얼마나 잘 충족시키는가입니다.

유지 관리는 유용성의 한 측면으로 생각할 수 있습니다.유지 관리가 쉬운 제품을 최우선으로 생각합니다.장기적으로 보면 관리자의 작업 시간을 많이 절약할 수 있습니다.

이에 대해 생각하는 한 가지 방법은 먼저 최종 사용자/관리자의 관점에서 가장 유용한 솔루션이 무엇인지 설계한 다음 해당 최적의 솔루션을 실제로 구현하는 것을 지적 과제로 만드는 것입니다.프로그래머의 노력이 더 필요할 수도 있지만 최종 결과는 더 좋을 것입니다.

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

또 다른 예로, 저는 최근 분산 데이터베이스와 애플리케이션 서버라는 향후 프로젝트의 유지 관리 방법을 계획하고 있습니다.일반적인 관리 작업(응용 프로그램 설치/업그레이드, 클러스터에 서버 추가/제거, 하드웨어 오류 해결 등)이 어떻게 발생하는지 생각하면 몇 가지 설계 결정을 내리는 데 도움이 되었습니다.그 중 일부는 시스템 아키텍처에 상당히 깊이 관여합니다(예: 런타임에 애플리케이션과 확장이 로드되는 방법, 서버가 클러스터에서 다른 서버를 찾는 방법).

다른 팁

Windows 시스템의 시스템에 단일 부호를 설정하면 광고를 사용하는 것이 매우 좋아집니다. SYS 관리자로서. 단일 소스 정책을 따르려고 노력합니다. 광고는 이미 내 Windows 사용자/보안 데이터를 많이 보유하고 있습니다. 나는 두 번째 시스템보다는 거기에있는 모든 것을 선호합니다.

Dev/Test/Prod 환경을 설정할 때 Prod One과 밀접하게 일치 할 때 특히 작업중인 지역 (개발 노력이 진행되는 곳 등)과 밀접하게 일치 할 수 있도록 노력합니다. 따라서 AD와의 인터페이스를 개발하기 위해 시스템을 설정하면 여러 AD 서버가있을 수 있습니다.

관리자를 단순화 할 수있는 옵션은 무엇입니까?

표준 방식으로 유지 관리하는 1 개의 마스터 서버를 가질 수 있고 VMware 사본 프로세스와 같은 것을 사용하여 다른 사람의 전부 또는 대부분을 유지할 수 있습니까? 9 개의 서버에 무언가를하는 대신 Dev/Test를 지원하기 위해 변경된 변경을 제외하고 다른 8을 해당 미러의 사본으로 유지합니까?

1 AD 서버에서 여러 Dev 또는 테스트 도메인을 실행할 수 있습니까?

행동을 스크립트 할 수 있습니까?

특히 높은 테스트에서 환경 수를 줄일 수 있습니까? EG는 여러 DEV 환경을 제공하고 역할 업 릴리스를 단일 테스트 하나에 제공합니까?

테스트 할 때 별도의 도메인 대신 OUS를 사용하지 않겠습니까? 즉, 단일 도메인이 있지만 특정 버전의 사용자는 해당 도메인 내부의 특정 OU에서 찾아야한다고 지정합니다. 당신이하는 일은 검색 기능에서 사용자를 찾기위한 것입니다. 특정 OU를 도메인의 루트 대신 검색 루트로 지정합니다. 각 OU에서는 환경을 통합하는 ID를 가질 수 있습니다. user_env1_dev, user_env2_dev, user_env1_qa, ...

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

공급자 패턴을 사용하고 데이터 소스 호출을 추상화하십시오.

그런 다음 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");
라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top