2009-04-22 69 views
6

这是我的情况...服务器维护何时应影响实施的决策?

我正在为需要单一登录过程的大型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

...所以,现在我已经把在上我自己som因为我将不得不维护所有这些机器(或虚拟机),这是我不确定我想要做的事情。

2)一切都不好。

原型非常稳固,AD为解决方案提供了一个非常好的数据库,但现在我想知道是否应该废弃代码并编写SQL Server数据提供程序(我知道.Net已经提供了一个,但它并不独立适合我的业务需求授权)。

无论如何,所以我试图从高层次角度考虑这个问题。总的来说,我一直绊倒这样一个事实,即仅仅因为某些服务器维护,我会抛出一个非常好的解决方案?我想知道这里有没有人遇到过这样的情况,以及你决定做什么。

不一定要针对AD,只是需要在良好的软件解决方案和服务器维护限制之间进行评估的情况。

+0

最后一个标记有一个错字:'programming-descisions' – 2009-04-22 22:55:28

+0

什么是“编程决定”标记even * mean *?它似乎没用... – 2009-04-22 23:45:04

回答

4

一般来说,产品的可用性是人们在它和类似产品之间进行选择的原因。如果产品的可用性差,用户不会关心其代码的质量如何 - 所有对他们而言都很重要的是它的使用是多么的简单和有效,以及如何满足他们的需求。

维护可以被认为是可用性的一个方面。我会优先考虑拥有易于维护的产品。从长远来看,这将节省管理员的许多小时工作。

首先从最终用户/管理员的角度设计什么是最可用的解决方案,然后将其作为实际实施最佳解决方案的智能挑战。它可能需要程序员更多的努力,但最终结果会更好。

例如ZFS是一种产品,其中维护得到了很好的照顾(尽管我没有亲自使用它)。设计时,通过使用ZFS的命令行工具轻松管理文件系统,以及这些设计决策影响所有ZFS级别(例如存储池),都付出了很多努力。作为另一个例子,我最近已经计划过我的未来项目 - 分布式数据库和应用程序服务器如何维护。思考典型的管理任务将如何发生(安装/升级应用程序,添加/删除集群中的服务器,解决硬件故障等),帮助我理清了一些设计决策。其中一些内容深入到系统的体系结构中(例如应用程序和扩展在运行时如何加载以及服务器如何在集群中查找其他服务器)。

+1

+1关于思考“典型管理任务”的意见。显然平均业务系统使用了7年。值得考虑维护。 – Karl 2009-04-22 22:56:20

1

如果在Windows系统上设置单点登录系统,我非常喜欢使用AD。作为系统管理员。我试图遵循单一数据源的策略。 AD已经拥有我的Windows用户/安全数据。我宁愿拥有所有内容而不是第二个系统。我设法确保与产品一致,特别是在正在开发的区域(正在进行开发工作的地方等)。所以如果建立系统开发与AD的接口,我可能会有多个AD服务器。

什么选项可以简化管理?

您是否可以拥有1台标准服务器,并使用类似VMware复制过程的方式来维护所有或大部分其他服务器?除了为支持dev/test所做的更改之外,不要为9台服务器做一些事情,将其他8台作为镜像副本保留在主服务器上?

你可以在1个AD服务器上运行多个开发或测试域吗?

你能脚本动作吗?

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

+0

>你能从1个AD服务器上运行多个开发或测试域吗? 我不认为你可以卡尔。这是我想要做的,但我一直在阅读这个日子,我不知道如何。 – 2009-04-22 22:42:57

+0

我并没有想到多国家/服务器;而是可以针对一个AD系统运行2个应用程序/代码库实例?我已经使用数据库完成了这项工作,它是否适用于您的AD? – Karl 2009-04-22 22:54:05

1

为什么不在测试时简单地使用OU而不是单独的域?也就是说,只有一个域,但指定特定版本的用户必须在该域内的特定OU中找到。你要做的是在搜索功能中查找用户,你可以指定特定的OU作为搜索根,而不是域的根。在每一个OU,你可以有ID,纳入环境,使他们独特的,例如,user_env1_devuser_env2_devuser_env1_qa,...

我用AD很多关于我的应用程序,并没有设立针对开发/测试不同的域。

+0

它已经被考虑过了,但它不会起作用,因为1)我们使用OU来表示其他对象,并且这两种用法的结合可能会让人困惑,2)安全边界考虑;虽然这是真的,但您可以指定用户所属的是OU和OU下的组的成员,但他们仍然可以在技术上针对该域进行身份验证。 – 2009-04-22 22:47:35

1

使用提供者模式并抽象数据源调用。

然后,您可以将其配置为实时使用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"); 
+0

很好的建议,但我已经在做:-)我有一个JSONDataProvider,我用它来测试所有。我必须抛弃的工作是我为构建“ActiveDirectoryDataProvider”库所做的所有工作。 – 2009-04-23 15:56:25