服务器维护何时应影响实施决策？

发布于 2024-07-17 03:06:10 字数 877 浏览 10 评论 0原文

这是我的情况...

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

...所以现在我给自己带来了一些管理上的头痛，因为我将不得不维护所有这些机器（或虚拟机），这是我不确定我想做的事情。

2）一切都不好。

原型非常可靠，AD 为解决方案提供了一个非常好的数据库，但现在我想知道是否应该废弃代码并编写一个 SQL Server 数据提供程序（我知道 .Net 已经提供了一个，但它没有仅满足我的业务授权要求）。

不管怎样，所以我试图从高层次的角度来思考这个问题。总的来说，我一直对这样一个事实感到困惑：仅仅因为一些服务器维护，我就会抛出一个非常好的解决方案？我想知道这里是否有人经历过这样的情况以及您到底决定做什么。

也不必特定于 AD，只是您必须在良好的软件解决方案及其服务器维护限制之间进行评估的情况。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

如若梦似彩虹 2024-07-24 03:06:11

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

在设置开发/测试/生产环境时，我尝试确保与生产环境紧密匹配，尤其是在正在开展的领域（正在投入开发工作等）。因此，如果设置系统来开发与 AD 的接口，我可能会有多个 AD 服务器。

哪些选项可以简化管理？

您是否可以拥有 1 台以标准方式维护的主服务器，并使用 VMware 复制流程等方式来维护所有或大部分其他服务器？除了为支持开发/测试而进行的更改之外，不要对 9 台服务器执行某些操作，而是将其他 8 台服务器保留为镜像主服务器的副本？

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

你能编写动作脚本吗？

您能否减少环境数量，尤其是在高端测试中？例如，提供多个开发环境并将发布版本整合到一个测试环境中？

回复收藏 0 原文

小矜持 2024-07-24 03:06:11

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

我使用为我的应用程序做很多广告，从来没有为开发/测试设置单独的域。

回复收藏 0 原文

贪恋 2024-07-24 03:06:11

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

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

Use a provider pattern and abstract your datasource calls.

Then you can configure it to use AD or SQL on the fly.

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 原文

撕心裂肺的伤痛 2024-07-24 03:06:10

一般来说，产品的可用性是促使人们在它和类似产品之间进行选择的因素。如果产品可用性不好，用户就不会关心其代码的质量有多高——对他们来说重要的是它使用起来有多容易和有效，以及它如何满足他们的需求。

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

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

例如 ZFS 是一款维护得很好的产品（尽管我没有使用过）个人认为）。在设计时，我们投入了大量精力，以便能够使用 ZFS 的命令行工具轻松管理文件系统，而这些设计决策会影响 ZFS 的所有级别（例如存储池）。

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

回复收藏 0 原文

~没有更多了~