【问题标题】:When should server maintenance affect implementation descisions?服务器维护何时应该影响实施决策?
【发布时间】:2009-04-22 22:22:41
【问题描述】:

这是我的情况...

我正在为需要单点登录过程的大量 Web 应用程序编写一个 .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,只是您必须在一个好的软件解决方案和它的服务器维护限制之间进行评估的情况。

【问题讨论】:

  • 最后一个标签有错字:'programming-descisions'
  • “编程决策”标签甚至是什么意思?好像没用……

标签: active-directory system-administration


【解决方案1】:

一般来说,产品的可用性是促使人们在产品和类似产品之间做出选择的原因。如果产品的可用性很差,用户就不会关心它的代码质量有多高——对他们来说,重要的是它的易用性和有效性以及它如何满足他们的需求。

维护可以被认为是可用性的一个方面。我会把拥有易于维护的产品作为首要任务。从长远来看,这将节省管理员的大量工作时间。

一种思考方式是,首先从最终用户/管理员的角度设计最有用的解决方案,然后让实际实施该最佳解决方案成为一项智力挑战。这可能需要程序员付出更多的努力,但最终的结果会更好。

例如ZFS是一款维护得很好的产品(虽然我没有亲自使用过)。在设计它时,投入了大量精力来简化使用 ZFS 的命令行工具管理文件系统 - 这些设计决策会影响 ZFS 的所有级别(例如存储池)。

作为另一个例子,我最近一直在计划如何在我的未来项目中进行维护 - 分布式数据库和应用程序服务器。思考典型的管理任务将如何发生(安装/升级应用程序、在集群中添加/删除服务器、解决硬件故障等),帮助我理清了一些设计决策。其中一些深入到系统架构中(例如应用程序和扩展如何在运行时加载,以及服务器如何找到集群中的其他服务器)。

【讨论】:

  • +1 为 cmets 关于“典型管理任务”的思考。显然avg业务系统使用了7年。值得考虑维护。
【解决方案2】:

如果为 Windows 系统设置单点登录系统,我很可能会使用 AD。作为系统管理员。我尝试遵循单一数据源政策。 AD 已经保存了我的大部分 Windows 用户/安全数据。我宁愿把所有东西都放在里面,而不是第二个系统。

在设置 dev/test/prod 环境时,我会尽量确保与 Prod 环境紧密匹配,尤其是在正在开发的领域(正在投入开发工作等)。因此,如果设置系统来开发与 AD 的接口,我可能会有多个 AD 服务器。

哪些选项可以简化管理?

您能否拥有 1 台以标准方式维护的主服务器,并使用类似 VMware 复制过程的方式来维护所有或大部分其他服务器?除了为支持开发/测试所做的更改外,不要对 9 台服务器做任何事情,而是将其他 8 台作为该镜像主服务器的副本?

您可以从 1 个 AD 服务器运行多个开发或测试域吗?

你能编写动作脚本吗?

您能否减少环境的数量,尤其是在测试的高端?例如。将多个开发环境和角色升级版本提供到一个测试环境中?

【讨论】:

  • > 您可以从 1 个 AD 服务器运行多个开发或测试域吗?我不认为你可以卡尔。这是我想做的,但我已经阅读了好几天了,我不知道怎么做。
  • 我没有考虑多域/服务器;而是您的应用程序/代码库的 2 个实例可以针对一个 AD 系统运行吗?我已经用 DB 完成了这个,它对你的 AD 有用吗?
【解决方案3】:

为什么在测试时不简单地使用 OU 而不是单独的域?也就是说,只有一个域,但指定特定版本的用户必须在该域内的特定 OU 中找到。您要做的是在查找用户的搜索功能中,将特定的 OU 指定为搜索根目录,而不是域的根目录。在每个 OU 中,您可以拥有包含环境以保持其唯一性的 ID,例如,user_env1_devuser_env2_devuser_env1_qa、...

我在我的应用程序中经常使用 AD,并且从不为开发/测试设置单独的域。

【讨论】:

  • 已经考虑过了,但它不起作用,因为 1) 我们使用 OU 来表示其他对象,将这两种用法结合起来可能会让人困惑,以及 2) 安全边界考虑;虽然您确实可以指定用户所属的组是 OU 下的组的成员,但从技术上讲,他们仍然可以针对域进行身份验证。
【解决方案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");

【讨论】:

  • 好建议,但我已经在做 :-) 我有一个 JSONDataProvider 用来测试它。我必须放弃的工作就是我为构建我的“ActiveDirectoryDataProvider”库所做的所有工作。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2020-05-30
  • 2011-11-26
  • 2011-02-15
  • 1970-01-01
  • 2012-09-05
相关资源
最近更新 更多